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PACKET 

RADIO? 


Packet radio is one of the newer modes of communication available to 
hams. It is also a mode with very rapid growth. Much of this growth is 
with new no-code hams who have had relatively little experience with 
ham radio. This chapter is intended for those of you who are just 
starting, or thinking of starting, with packet. 


1.A WHAT IT IS 


Digital methods of communication have been around since the very start 
of radio. CW (ie, Morse code) is really digital. The transmitter is 
switched on and off to convey information. In this mode, the relative 
duration of the on times and off times carries the information. 


Voice varies some characteristic of a transmitter in proportion to the 
strength of the electrical signal coming from a microphone. The 
characteristic can be amplitude; this results in AM (amplitude modulated) 
or SSB (single side-band) transmissions. The characteristic can be 
frequency which results in FM (frequency modulated) transmissions. 


After World War II, military and civilian teletype machines became 
available to hams. They were adapted to radio use and the result is 
RTTY (Radio TeleTYpe, often spoken as "ritty"). This is also a digital 
mode, but quite different from CW. This style of operation keeps the 
transmitter operating continuously rather than on-and-off. One mode 
sends a tone (rather like a voice signal but a single frequency). The data 
is carried by switching the tone frequency (ie, pitch) back and forth 
between two specific values. This is called audio frequency shift keying 
or AFSK. The other mode shifts the transmitter frequency back and 
forth between two values. This is called frequency shift keying or FSK. 
RTTY works fairly well... except that it is not a very efficient use of our 
limited frequencies, and it works more and more poorly as conditions 
become crowded. 


Packet radio is one of several "modern" extensions of RTTY. Depending 


on the operating frequency, packet may send much more rapidly than 
RTTY. It also has error correcting which RTTY does not. Packet is not 
the only such mode: AMTOR is another and CLOVER is a third. Both of 
these are considered "better" for use on lower frequencies and packet 
"better" for VHF. Packet may use FSK or AFSK; on VHF at standard 
character speeds, AFSK is commonly used. 


Packet uses a protocol called AX.25. A protocol is a set of rules. In this 
case, the set of rules tells how characters a bundled together into a 
collection called a packet. It also tells how stations connect with each 
other and how errors are handled (see Chapter 10 for more information). 


Thus, packet is a technique for sending and receiving characters. These 
characters usually represent typed text. But packet is not limited to 
straight text since any computer file such as a program is also 
represented by a set of characters. 


1.B WHAT HAMS TO WITH PACKET RADIO 


Packet radio is used for a great variety of things. The first which comes 
to mind is the hallowed QSO, the face-to-face, or in this case, 
keyboard-to-keyboard, conversation. QSOs are a big part of packet, 
also. But, percentage-wise, it makes up a smaller fraction of activity than 
most other modes. 


So, what is the rest of the activity? Much of the message passing is 
through the medium of the bulletin board (BBS). This is basically like 
letter writing! Often, messages are left in the mailbox contained within a 
specific station's modem. Other times, messages are in independent 
bulletin boards. These are able to transfer messages from one BBS to 
another, automatically. 


Many hams immediately think of emergency communications when they 
learn about packet radio. Indeed, under some circumstances, it works 
very well (see section 1.C). 


Some of the other ham activities, such as DX, are more difficult. HF 
bands are preferred. Packet on HF takes a good deal of skill. 


Many hams use packet in conjunction with other ham activities. One of 
the major ones is "DX spotting". In this case, packet is used as a method 


for DX operators to notify each other when new DX stations appear on 
HF. 


Traffic handling is another traditional ham activity and packet is useful 
here, also. It is particularly suitable with complex messages; the error 
correcting can improve accuracy. Traffic handling on packet is 
particularly useful in emergency situations where large amounts of 
"health-and-welfare" traffic are involved. 


1.C WHAT IT WORKS WELL FOR 


With the preceding summary of ways in which packet is used, it might 
seem to be a "universal" solution to amateur communications. Nothing 
could be further from the truth. 


Packet is not very efficient on HF. AMTOR and CLOVER are usually 
superior in terms of frequency use and achieved character rate. This is a 
measure of how rapidly characters get delivered at the receiving end. It 
takes into account the error rate and everything which must be done to 
fix the errors. Packet is usually the preferred mode on VHF using FM. 
On VHF, tones are usually used, so it is FM-AFSK. At higher baud rates, 
true FSK is commonly used. 


In emergency communications, packet does not work very well for 
tactical communications. This includes things such as base-camp to 
search-crew communications. Where it does work, and work very well, 
is strategic communications. This sort of work usually involves lists: 
"Avenue-A shelter needs 23 cots, 47 personal meal packs, ....". Packet 
insures accuracy in such situations. Incoming health-and-welfare 
messages trying to locate displaced individuals is another effective 
emergency use. Such messages can easily be circulated among shelters 
or other sites. Likewise, lengthy detailed reports from county emergency 
centers to regional or state centers are often handled by packet. 


DX spotting also works well. These DX Clusters or DX Spotting 
Systems are widely distributed. In areas with substantial population 
density, several of these are often linked together. 


Traditional QSOs are not as easy as one might like. This is especially 
true over long distances. Even though there is a network linking widely 
separated points, it does not always work that well for simple 
conversations. 


BBS "mail" can work well or poorly, depending on local conditions. It 
may take only a few hours to move a message from coast to coast. But 
it may take that long or longer to move messages through a major 
metropolitan area. 


From this discussion, it should be apparent that there are lots of 
interesting things to look for in packet. And just because something 
"works poorly" is not a reason to give up on it. This is an area where 
change is frequent. Ideas for improvement can make a difference. And, 
you need not be a computer professional to have fun! 


The Amateur Packet Radio Handbook Chapter 2 
Copyright James Wagner, 1993 EQUIPMENT 


There are three basic pieces of equipment which are needed to operate 
packet. These pieces are (broadly): (1) a radio and the support stuff 
needed to make it work, (2) a modem, and (3) a terminal. 


2.A TERMINALS 


A terminal is a device you type on to send messages. It also displays 
messages which come to you. Terminals come in many forms (and 
prices). 


2.A.1 DUMB TERMINALS: In principle, almost any terminal can be 
used with a packet modem. Many who do not already have a computer 
look at dumb terminals or glass teletypes because they can be very 
inexpensive. So long as they are RS232 ASCII devices, they will work. 
But using one puts you at a real disadvantage. Once the text has left the 
screen, it is lost, forever. These devices very rarely have the ability to 
save incoming text. On the other hand, if your goal is to do packet at an 
absolute minimum cost, you might find this attractive. If this is the case, 
do not overlook some of the alternatives mentioned below. 


2.A.2 OLDER COMPUTERS: Many older computers can be quite 
inexpensive and attractive so long as suitable software is available. A few 
still use Apple Ils (though software is scarce). Commodores, (especially 
C64s) are quite often used; several modem manufacturers provide 
software for C64s. You must be careful about using C64s because the 
serial input/output is "TTL" rather than RS232; either a special adaptor or 
a modem which accepts TTL is needed. Potential C64 buyers are well 
advised to avoid "C64+4" machines. These are not compatible with 
standard C64s and software in nearly nonexistent. TI-99, Commodor 
VIC-20 & PET, and Apple Lisa computers are also to be avoided. 


Older 8086-based IBM-style PCs are available for a few hundred dollars 
or less. This will not get you a hard-disk or color monitor but you really 
do not need either of these. You do need at least one RS232 serial port. 
The '186 and '286 computers are also good but may cost a little more. 


2.A.3 MODERN COMPUTERS: Newer computers of all kinds are 
acceptable. These include '386 & '486 PCs, Macintoshs, and UNIX 
workstations. There is a variety of software available although seldom 
written specifically for packet operation. Many people (including the 
author) have never used packet-specific software and are able to make 
the packet system do everything for them which anybody else can do. 
Laptops work well for mobile and portable packet. Palmtops can often 
work although the key size can make typing difficult. Some data 
organizers will also work but check very carefully before purchasing one. 


See Chapter 18 in Volume 2 for discussion of packet terminal software. 


2.B MODEMS 


There are several types of modems in common use. But before 
discussing modems, lets look at what they need to do. Usually, in 
packet radio, the modem is responsible for managing the message 
construction, connection, error correction, and mailboxes, to name just 
a few functions. The modem must also carry out the conventional 
modem tasks of converting logic signals into a form suitable for radio 
transmission. To do this, the modem has two parts. One is the classic 
modem (which, at lower baud rates, uses audio tones). The second part 
is really a specialized computer which carries out the packet-specific 
functions. 


TO/FROM 
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TERMINAL 


SERIAL 
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FIGURE 2-1, TNC BLOCK DIAGRAM 


To be fair, it should be noted that there are situations in which a 
computer carries out the packet-specific functions and a true (and 
simple) modem is used. Several of these are actually quite popular 
because of very low cost (see DigiCom and BayCom, below). 


2.B.1 TNC2's: Of the conventional packet modems, a very common 
type is the TNC2 clone which is made by several manufacturers. The 
term TNC stands for terminal node controller. These include the 
MFJ-1270 and MFJ-1274. There are several made by other 
manufacturers which are functionally quite similar to the TNC2 types 
but have different (but similar) commands and capabilities. These 
include the AEA PK-232s & PK-232MBXs, and Kantronics KPC3s. 


2.B.2: MULTIMODE CONTROLLERS: These handle modes such as 
AMTOR and RTTY in addition to packet. These are of little use unless 
you plan to operate on HF. 


2.B.3: BayCom MODEMS: The BayCom modem is a true modem 
which relies on an IBM-style computer to carry out the packet related 
functions. It requires special software to make it operate. 


2.B.4: Digicom MODEMS: Similar to BayCom but specifically for 
Commodore C64 computers. 


2.B.5: THE DATA ENGINE is a relatively new device which is 
targeted specifically at high speed operation. It can operate with two 
radios and is particularly well suited for use with bulletin boards and 
nodes. 


2.B.6: CROSS-BAND TNC's: Kantronics makes some specialized 
TNCs which are particularly designed to operate simultaneously on one 
HF frequency and one VHF frequency. The form of operation is often 
referred to as a KaNode. They are frequently available for use by others. 


2.B.7: EXPANSION-SLOT PACKET MODEM: These are cards which 
plug directly into expansion slots in computers (usually PC/clone). Some 
may act, as far as computer software is concerned, as a serial card. 


2.B.8: MODEM-COMPUTER CONNECTION: Along with the modem, 
you need a cable to connect the modem to your terminal. Most TNCs 
appear to provide a DB-25 female connector. The other end must match 


your terminal, whether it is DB-25, DB-9, DIN, or other. Many TNC 
manufacturers make available cables for specific computers (usually at 
extra cost). 


A list of packet modems and their manufacturers is included in Chapter 
19 of Volume 2. 


2.C ANOTE ABOUT MODEM COMMANDS 


Not all TNCs use exactly the same commands. The commands which 
are used in this book are generally the TNC2-clone commands. Where 
alternative commands are known, they are indicated. In general, a name 
or description is used with the command. If you look up in your 
instruction manual using the the descriptive words used here, you should 
come close. If you do have problems, feel free to contact the author. 


2.D RADIOS 


Most hams come to packet radio with a radio they use for other 
purposes. It is a very rare situation where we have the luxury of 
selecting something specifically for packet. As a result, the most 
commonly used radios are hand-talkies or mobile radios. But if we know 
a little about what makes a radio good for packet, better choices can be 
made when the time comes to get that new(er) radio. 


2.D.1: RADIO CHARACTERISTICS: Transmit/ Receive (T/R) 
switching is a significant factor. Many older radios use mechanical 
relays for switching. These relays are both slow and rapid to wear out. 
One of the aspects of packet as compared to voice is the much more 
frequent change from receive to transmit. Thus, relays tend to fail more 
quickly. The slow switching time adds to transmitter keyup time. The 
consequences of this are discussed in section 2.F. 


Many of the older synthesized radios take some time to settle in frequency 
(even in simplex operation) when changing between receive and transmit. 
This may cause the start of the packet of other stations to be missed, for 
example. Here, the best advice is experience of other packet operators. 


2.D.2: MODEM-RADIO CONNECTION: One of the long standing 
problems in assembling a packet radio station is connecting the modem 
to a radio. There is usually some information in the instructions with the 


TNC. If the radio is fairly new, there may also be information in its 
instructions. 


Many TNCs, perhaps most, come with a radio cable. When it is 
supplied, it almost always comes without connectors on the radio end. It 
is your problem to make that final link. To make the connection, you 
must determine one crucial piece of information about the radio: how 
does the transmitter key? To determine this, you need to look at the 
audio connector(s). If the connector is a multi-pin circular connector 
(commonly used for speaker-microphones or microphones with 
telephone keypads or microphones with radio control buttons) determine 
whether one of the pins is a PTT (push-to-talk) function. If so, the 
transmitter keying is separate from audio. If the only connector(s) are 
miniature audio jacks (common on handi-talkies), inspect the 
microphone jack. If the jack takes a 2-circuit plug (like a stereo plug), 
then transmitter keying might be separate from audio. If the transmitter 
keying is not separate from audio, then it is combined with audio (and 
almost always with transmit audio). 


With many TNC's an internal jumper must be added for combined PTT 
and transmit audio. With others, the PTT and transmit signals must be 
combined as part of the wiring between the TNC and the radio; in this 
case it may be necessary to connect transmit audio throught a capacitor 
and PTT through a resistor to a single terminal of the radio. Check your 
both radio and TNC instructions for the information about how to do 
this. If you have purchased your TNC used, verify that this jumper is 
appropriate for your transmitter. 


2.D.3 ANTENNAS: It is not always obvious what antenna arrangement 
is "best" for packet radio. One general rule is that operation will be 
much better if you can locate an antenna away from your TNC and 
terminal. 10-20 feet (3-6 meters) will generally be sufficient unless your 
computer is particularly noisy. 


One of the big arguments concerns non-directional vs directional 
antennas. Most of if this discussion will be postponed until section 2.E 
because you may not be able to tell until your station is in actual 
operation. At this point, it is worth mentioning that part of the choice is 
determined by the geographical pattern of stations (and nodes) in your 
area. If you will likely connect directly with stations in a variety of 
directions, then an non-directional antenna may be best. But if most of 
your work is likely to be in one direction, a beam may be better. You 
should not offend anybody if you start with an non-directional antenna. 


2.E ASSEMBLING YOUR PACKET STATION 


After gathering the basic pieces, there comes a time when you need to 
go ahead and "do it". This section will suggest a step-by-step process 
you may be able to use. This assumes that you are not using a TNC in 
KISS mode; if you want to do so, please try it simpler first! In the 
following, text you type is ITALICIZED . 


2.E.1 SETTING UP A TNC & COMPUTER: Now, lets get specific 
about TNCs and computers. 


SETTING UP THE MODEM 


Step 1: Connect your terminal to the modem. Few cases require more 
than a 3-wire RS232 link. Again, see Chapter 20 (Volume 2) for 
suggestions. 


Step 2: Connect the power source to the TNC. Most TNC's require 12V 
DC. This may come from a wall adaptor provided with the TNC or it 
may come from the transceiver power. Be VERY CAREFUL that power 
is connected in the correct polarity or you may destroy the TNC! Leave 
the power OFF at this point. 


Step 3: Turn on the terminal. If it is a computer, start the terminal 
program. If the program is a conventional terminal emulator, then 
proceed. If it is a more elaborate program (such as LanLink, TCP/IP, 
etc) follow the program's instructions. Many of these require 
configuration files to begin. You may find it easier with a simple 
"terminal emulator" at the start (see Chapter 18, Volume 2). 


Step 4: Configure the terminal serial parameters (except for BayCom or 
DigiCom). You need to read the TNC's instructions to determine the 
TNC's default serial parameters. It appears that TNC2 clones default to 
1200 baud, even parity, and 7 bit data; you need to set your terminal to 
the same. You should also try "full duplex". Later, you will be able to 
find out if the latter choice is correct. 


Step 5: Apply power to the TNC. (Ignore for BayCom) The power 
light, if there is one, should turn on. You should see on the terminal 
screen a "log-on message". This often gives the manufacturer's name, 


the software version, and perhaps some memory information. 


Step 6: (Ignore for BayCom or DigiCom) If no message is seen, try 
pressing the "enter key" several times. A few TNCs require some 
characters from the terminal to determine the baud rate. If you still do 
not see anything, retry the power several times. If you still do not see 
anything, try other combinations of parity and data bits. If you still do 
not see anything, make certain that the terminal serial output is 
connected to the modem serial input and that the terminal serial input is 
connected to the modem serial output. 


Step 7: Send a "command mode character" to the TNC from the 
terminal. For default TNC2 clones, this is "control-C". Check in your 
TNC instructions for information if control-C (which will be abbreviated 
"AC" from now on) does not work. With acommand mode character, 
you should see the command mode prompt on the screen. Again for 
TNC2 clones, this prompt is "cmd:". Once you get this, you are 
"half-way there”. 


Step 8: Program the TNC operating parameters. First and foremost is 
you callsign. For TNC2 clones, you type MYCALL callsign where 
"callsign" is your call. Nodes and other stations will not permit you to 
connect with the default call which is often "NOCALL" Some TNCs 
may require you to specify different callsigns for the mailbox and 
digipeating; see comments about "SSID" later on and check in your area 
for the standard practice concerning these assignments. 


I do not change many of the defaults. What is particularly important at 
this point is TXDELAY (TNC2 term). To start with, until you know 
how your radio works, set TXDELAY fairly long. This sets the interval 
between when the transmitter is told to start and when signal is actually 
applied. I use TXDELAY 60 which sets 600mS (0.6 seconds). This 
amount should be fairly good for most medium to slow radios. 


You should now have a working computer-TNC combination! 


Step 9: (Ignore for BayCom) Set RF baud rate on TNC if it is a HF/VHF 
unit like TNC2s. Many of these TNCs have a switch which controls the 
baud rate (and tone combinations) used over the air. This need not be 
the same as the computer-TNC baud rate. In general, 1200 baud is used 
on frequencies higher than 10 Meters and 300 baud is used on 
frequencies below 10 Meters; both are used on 10 Meters. 


Step 10: Connect your radio to the TNC. See Chapter 21 (Volume 2) for 
suggestions. 


2.E.2 RADIO SETUP: Once the terminal and TNC are operating, the 
radio is the next item. 


RADIO SETUP 


Step 1: Connect a dummy load to your radio. If you don't have a 
dummy load, set it to lowest output power and use the worst antenna 
you have. For most of us, this is probably a "rubber duckie". 


Step 2: Turn on the radio. It should not immediately transmit. There 
should be some kind of transmit indicator which tells you whether or not 
it is being keyed. This may be a light or some other indicator. 


Step 3: Set your radio to simplex and tune to one of the packet 
frequencies. In the U.S., these are generally 144.900 MHz to 145.100 
MHz. You will first want to choose a frequency not in general use. It is 
pretty safe to use an "even" frequency such as 144.92 or 144.94 because 
the commonly used frequencies are 144.91, 144.93, etc. 


Step 4: With the TNC in command mode (from Step 7 of "Modem 
Setup"), enter a connect command. Since you will not really be 
connecting to anything, use any call or alphabetic name with 6 or fewer 
characters. An example might be: C W7ABC. 


Step 5: You should see the PTT (push-to-talk) indicator on your TNC 
flash at regular intervals of a few seconds. Likewise, the transmitter 
must key every time the PTT indicator flashes. If so, you have the 
transmitter keying line properly connected. 


Step 6: After a number of tries, the TNC should stop and you should see 
a message on the screen which says something like "*** retry count 
exceeded". 


Step 7: Connect your radio to the antenna you expect to use. Select a 
frequency with packet activity. You can find this by disconnecting the 
TNC from your radio and listening as you tune from 144.90 to 145.10. 
On a packet frequency in use, you will hear rather irritating buzzes. Plug 


the TNC back into the radio when you find a frequency. 


Step 8: The DCD (data carrier detect) indicator on your TNC should 
flash regularly as packets are received. If not, adjust the volume control 
on the receiver. If there is still no DCD, you may not have received 
audio connected properly. Also, make certain that the RF baud rate 
setting on the TNC fits the situation you are operating. 


Step 9: Assuming that the DCD indicator does flash, now try to monitor 
activity. For TNC2s, the command is MON ON ; for AEA TNCs, try 
"M9". You should now start to see lines of strange characters 
appearing on your screen. In the font which will be used from now on 
to show text which the TNC sends to your terminal, it might look like: 


KA7ZIN-15>N7ICS <RR R F R4> 

SALEM>KA7ZIN <RR R F R4> 

SALEM>KA7ZIN <RR R F R5> 

KA7ZIN-15>N7ICS <I C P S3 R4>:Yeah, tell me about 
it. Well I will let u continue. 73, cul, KA7ZIN 
K 


You may need to adjust the transceiver audio level to get consistent 
copy by your TNC. 


Step 10: You now need to set the deviation for your TNC and 
transceiver. In a sense, this is the loudness of your signal. Most TNC's 
have a transmit audio level adjustment. Remove the cover of your TNC 
and locate this adjustment with the aid of the instruction manual. You 
will need a small screwdriver (about 1/8" or 3mm blade). To initially 
make this adjustment, it is very desirable to have the use of another VHF 
radio. Tune it to the same frequency as you are using. Listen to other 
signals. Some of them may be weak with "hiss" in the back-ground 
while others will be fairly clear. Concentrate on the loudness of the clear 
signals. 


Now, in command mode, type CAL or the equivalent for your TNC for 
calibrate. Press K to key the transmitter and note the loudness in your 
other radio. Don't leave your transmitter on any longer than absolutely 
necessary; press K again to turn it off. If your loudness is not similar to 
the others which you heard, adjust the transmit audio level in the TNC 
and try it again. When it is adjusted, type Q to return to normal 
operation. 


This is a preliminary adjustment. See Chapter 22 (Volume 2) for detailed 
information about adjustment of deviation. You should now be ready for 
some on-the-air communication! 
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Here, a local conversation is one not using a node. Please note: in many 
areas, it is not considered "good practice" to carry on a conversation on 
a frequency with a local node without using that node; the reason for 
this should become clearer in Chapter 4. This section will show you 
how to make a connection without using a node. Understand that this 
may just be a learning step, depending on your local practice. 


The following typographic conventions will be used in this and following 
sections: text FROM another station (including a node or BBS) are in this 
font; text from your TNC is in this font; text you type is italicized. (note 
that it does NOT appear italicized on your screen!) 


A very useful metaphor for various aspects of packet radio is the 
telephone system. This will be used over and over to try to make the 
concepts somewhat more intuitive. 


3.A MAKING A CONNECTION 


Making a direct connection is like calling someone up on an old-style 
party line. You didn't need to use the operator. You could call the 
Smiths down the road by ringing 2 long rings and | short ring on the 
hand-crank phone. 


You can do the same on packet. If you want to talk to W9ABC, you 
tell your TNC: "connect me to W9ABC". The TNC constructs an 
appropriate packet with your call, the call of the station you want to 
connect to, and the request to connect. The TNC causes this message 
to be sent out on your radio and it listens for a response from the other 
station. If there is no response, it tries again; this is called a "retry". The 
TNC tries a number of times controlled by a value which you can set in 
the TNC, then gives up if there is no answer. 


3.A.1 FINDING SOMEONE TO TALK TO: One of the big questions 
asked by almost every new-comer to packet is: "How do I find 
somebody to talk to?" This question needs to be answered before 
discussing how to make your first connection. The way to start out is 


to use the "heard" list kept by your TNC. In TNC2 clones, you get this 
list in the following way: 


cmd: mh 

AF7S-1 24-02-93 15:04:45 
KB7QQH 24-02-93 15:04:18 
SALEM 24-02-93 15:04:17 
AATJI 24-02-93 14:57:42 
WA7SMO-15 24-02-93 14:54:39 
K7IQI 24-02-93 14:53:13 
K7MYU 24-02-93 14:51:39 
N7ICS 24-02-93 14:41:43 
K7UN 24-02-93 14:36:49 
WA6SDR 24-02-93 14:13:09 
cmd: 


Note that this list comes from your TNC. Don't worry if yours does not 
have time and date or looks a little different. Note that some are not 
normal calls but names, like "SALEM" in the list above. These are 
usually from nodes or bulletin boards. Others are more-or-less "normal" 
ham calls. A few others look like ham calls with numbers on the end. 
These numbers have been referred to before as "SSID"s (Secondary 
Station ID). Many SSIDs indicate a node or a packet which has passed 
through a node; this will be discussed in more detail in later chapters. 
Others indicate mailboxes. Those callsigns without SSID's are prime 
candidates to talk to. 


3.A.2 MAKING A CONNECTION: Lets try to connect to a station 
which isn't on the list. To request a connection, after the command 
prompt (remember that this means that you are "talking" to the TNC), 
simply use a C (for connect), a space, and the callsign, like this: 


cmd: c_ w/abc 


The TNC and radio will try several times. If the station really isn't there, the TNC 
responds with: 


cmd:*** retry count exceeded 
*** DISCONNECTED 


This message tells you that the TNC tried in vain. Here is what happens 
when a connect is tried to a station which IS on the list: 


cmd: c_ kb7hqj 

cmd: *** CONNECTED to KB7/HGJ 

Please leave message @ KB7HGJ-1 Thanks <de Kevin> Chehalem 
Mtn. Newberg,Or. 

Hello, anybody home? 

cmd: d 

cmd: *** DISCONNECTED 


Lets walk through what just happened. The connect command was 
given in the Ist line. The TNC responds with the *** CONNECTED to 
KB7HG]J message in line 2. This message comes from the TNC, not the 
other station. The other station, in this case, responds with a "connect 
message" in lines 3 & 4; this tells you to connect to KB7HGJ-1 in order 
to leave a message (see mailboxes in the next section). The typed query 
in line 5 goes unanswered, so a disconnect was made in line 6. This 
does not really show how the disconnect happened. In these simple 
cases, you must tell you TNC to disconnect you. Thus, YOU have to 
place the TNC into command mode; for most TNCs, a control-C (no 
ENTER or RETURN is needed) does it. The d is short-hand for 
"disconnect" and the TNC informs you when the task is finally 
accomplished. 


Now, if someone actually had been on the other end, you could type 
back and forth. Once the connection occurs, the TNC automatically 
switches into "converse" or conversation mode. In this mode, the TNC 
is rather transparent, just sending on through (within some limits) what 
you type. Similarly, it receives what was typed on the other end and 
presents it to your terminal for display. 


3.B MAILBOXES 


Many TNC's have built in mail-boxes. If you leave your radio and TNC 
turned on all the time, other packet stations can leave mail in your TNC. 


Mail-boxes are much like simple bulletin boards so we won't go into 
great detail now. There are several styles. A common one looks like 
this when you connect: 


[KAM-5.0-HMS] 

6218 BYTES AVAILABLE 

Welcome to Oregon, please leave me a message. 
ENTER COMMAND: B,J,K,L,R,S, or Help > 


H 

B(ye) PBBS WILL DISCONNECT 

J (heard) CALLSIGNS WITH DAYSTAMP 

J S(hort) HEARD CALLSIGNS ONLY 

J L(ong) CALLSIGNS WITH DAYSTAMP AND VIAS 
L(ist) [7] LIST MESSAGES YOU CAN READ 

L <|> call LIST MESSAGES FROM OR TO CALL 

LB LIST BULLETINS 

LC [cat] LIST CATEGORIES 

LL n LIST LAST n MESSAGES 

LM (ine) LIST UNREAD MESSAGES ADDRESSED TO YOU 
LT LIST TRAFFIC 

K(ill) n DELETE MESSAGE NUMBER n 

KM (ine) DELETE ALL READ MESSAGES ADDRESSED TO YOU 
R(ead) n DISPLAY MESSAGE NUMBER n 

RM (ine) READ ALL MESSAGES ADDRESSED TO YOU 
S(end) call SEND MESSAGE TO callsign 

SB call SEND BULLETIN 

SP call SEND PRIVATE 

ST call SEND TRAFFIC 


ENTER COMMAND: B,J,K,L,R,S, or Help > 


While this one may be a little more elaborate than some, it is not much 
different than many of the mailboxes on the air. You can disconnect by 
sending it a b (for bye) or you may disconnect from your end. 


There is one important distinction between mailboxes; some are full-time 
and some must be turned on and off. Full-time ones usually use a 
specific SSID for the mailbox and another SSID for "talk" with the 
operator (as in the example of the previous section). Part-time 
mailboxes use only one SSID; these must be turned on when keyboard 
operation is completed, then turned off when keyboard operation is 
restarted. 


3.C DIGIPEATING 


What do you do when the station you wish to talk to is not quite in radio 
range? The first solution developed for packet radio is called digipeating. 
While still used, it is no longer the only solution. It has its place and its 
limitations which are discussed in the last section of this chapter. 


3.C.1 CONNECTING USING A DIGI: Digipeating uses one or more 
other stations to relay your message to a distant destination. Lets 
suppose that you are on one side of a mountain, W7ABC is on the other, 
and, as in our example in section 3.B, connect requests are not 
successful. Lets suppose that AA3ZZ is fortuitously located on top of 
the mountain. See Figure 3-1. We can use AA3ZZ as a digipeater (or, 
digi for short) by requesting that our TNC try to connect to W7ABC via 
AA3ZZ. The command to the TNC looks like this: 


cmd: c wvabc v AA3ZZ 


There are several things to note from this command. One is that 
callsigns can be entered in either upper or lower case. You can spell out 
via or use the shorthand, v . 


FIGURE 3-1, DIGIPEATI 


If more than one digipeater is used (the packet format permits up to 8), 
the digipeater callsigns are listed in the order in which the packet 
encounters them leaving your station, separated by commas. Thus, an 
acceptable request might be 


cmd: c wvabc v AA3ZZ, NIA 


where AA3ZZ is the first digipeater encountered by your signal, N1A is 
the second, and W7ABC, your destination, is the last. 


3.C.2 HOW DIGIPEATING WORKS: Every packet has a portion 
which you do not normally see. This portion, the header, contains the 
call of the station which sent the packet and the call of destination of the 


packet. There is also room for a number of digipeater calls. 


When a station which is able to digipeat hears its callsign in the digipeat 
call portion of the header, it listens to the packet. If the packet is 
received error-free, it resends it. In this way, a whole chain of stations 
may pass a packet from one to the next. 


-_D LIMITATIONS 


In the early days of packet radio, digipeating was widely used. One 
could use a string of digis to go all the way from Portland, Oregon to San 
Francisco. If this is possible, why is it not as widely used now? 


One answer is that digipeaters don't know anything about neighboring 
digis. You have to find out by asking and exploring. Nodes have solved 
this problem by managing routing in a much more straight forward 
manner. 


Another answer has to do with error management. Suppose, in our 
previous example, there was noise which interfered with one of your 
packets as it was sent by AA3ZZ to W7ABC. If the error wasn't too bad, 
W7ABC sends back a packet saying that there was an error and your 
TNC repeats. If the error was really bad, W7ABC's TNC does not even 
know that there was a packet and simply does not acknowledge (which it 
does with a successful reception). In this case, also, your TNC waits, 
then repeats. In both cases, the packet gets resent from you to AA3ZZ 
and from AA3ZZ to W7ABC. Thus, the repeat packet is resent twice, 
occupying the frequency twice. If a node were used instead of a digi, the 
error is resolved between the node and each participant. Repeat packets 
are only sent between the node and the end station. 


Even with these limitations, digipeating still has its place. If you are out 
of range of a node, digipeating may be an answer. If your local node 
fails, digipeating may also help (temporarily). Thus, while of more limited 
use than in the "good old days", digipeating still has a place if used wisely. 


3.E ANTENNAS 


As mentioned earlier, antennas are a major discussion point. Among 
packeteers, the issue is usually between directional and non-directional 
antennas. Here, we will try to look at the advantages and disadvantages 
of each. In general, the conclusion seems to be that there is no one 
"right" answer. It may, in fact, take some experimentation to determine 
what is best for you. Lets first talk about some of the issues before 
looking at how each antenna type stands up. 


3.E.1 MULTI-PATH: Multi-path is a problem which arises when radio 
waves follow two different routes from the transmitter to the receiver. 
The end result happens when the two routes are of different length. If 
the length differences are just right, the two signals can interfere with 
each other "destructively". Multi-path is quite obvious when watching 
television; it produces the irritating "ghost" images. It can also be quite 
obvious when operating VHF mobile; there are spots where signals fade 
almost completely and there are others, often only a few feet away, 
where signals are strong. 


The effect can be seen on any frequency, including HF. It is easily seen 
on VHF and often seems more pronounced as you go up in frequency. 
For a variety of reasons, multi-path problems increase at higher RF baud 
rates. 


3.E.2 HIDDEN TRANSMITTERS: The hidden-transmitter problem is 
as old as packet radio. This problem is the result of the "carrier sense" 
scheme which TNCs use to avoid packet collisions. A collision occurs 
when two packet stations transmit at the same time, spoiling all or part 
of the other's packet. TNCs try to avoid this by not transmitting when 
another is transmitting. But if a frequency is vacant for a little while, 
two TNCs may decide to transmit at about the same time, each unaware 
of what the other is going to do. This part is an unavoidable 
consequence of time-shared operation with the protocol (set of rules) 
which govern our TNCs. 


The hidden transmitter problem is in addition to the situation just 
described. To see its causes and effects, lets go back to section 3.C 
where digipeating is discussed. In that example, there is a hilltop station, 
AA3ZZ. It serves as a digipeater for two stations, (you and W7ABC) on 
opposite sides of the hill. Now, suppose that W7ABC has started to 
transmit. Your station cannot hear it because it is on the other side of 
the hill. So, your station can transmit, oblivious of the other station. 


AA3ZZ is now in a tough situation because it hears both at the same 
time. This is the hidden transmitter problem. 


3.E.3 NON-DIRECTIONAL ADVANTAGES: Non-directional antennas 
have been the historical choice for many packet stations. The reasons 
are fairly clear. With stations in a variety of directions, non-directional 
antennas are much easier. Particularly when digipeating is involved, 
signals may come from several directions at the same time, making 
non-directional antennas almost a requirement. 


Non-directional antennas are fairly inexpensive to purchase when 
compared to directional antennas. Because of simpler construction, 
non-directional antennas tend to be more resistant to severe weather but 
this is not always true. 


Non-directional antennas are simple to construct. J-poles and 
gound-plane verticals are frequently used. 5/8-wave verticals can supply 
some gain over a 1/4-wave vertical at the expense of a little more 
complexity. 


3.E.4 NON-DIRECTIONAL DISADVANTAGES: One of the major 
disadvantages of non-directional antennas is the inability to discriminate 
between signals involved in multi-path problems. 


3.E.5 DIRECTIONAL ADVANTAGES: The gain of a directional 
antenna may provide enough added signal on both receive and transmit 
to improve operation in low-signal areas. If low signal strength is 
causing retries, the packet rate from your station (and whom ever you 
are connected to) will improve. The reduced retry rate will reduce the 
time your packets occupy the frequency. 


If multi-path is a problem at your location, a directional antenna may 
improve the situation considerably. It is somewhat tricky to aim the 
antenna for best results, but when you do, the improvement can be 
considerable. 


3.E.6 DIRECTIONAL DISADVANTAGES: A directional antenna makes 
it difficult for other stations to use yours for a digipeater. In most areas, 
this is not an issue; but where it is, consider it. If you use nodes in a 
variety of directions, you may have to re-aim your antenna for each one. 
This is annoying and you are out the cost of an antenna rotor. 


A directional antenna may make it difficult for your station to hear others 


on the same frequency. Thus, you and those stations become hidden 
transmitters to each other. This effect may increase problems rather 
than decrease them. 


3.E.7 TESTING: If you have decided to try a directional antenna, it may 
be worthwhile to borrow one for a short time to see if the results are 
worth the effort. 


One of the best tests is to make a side-by-side comparison with your 
normal antenna. Set the two antennas up, a short distance apart. Bring 
coax from both to a point where you can easily change from on to the 
other. A useful measure is the retry rate. Try connecting to a station or 
a node (see next chapter). Send a very simple packet (maybe one with 
just a question mark). Watch how many times the PTT light flashes 
before the STA light goes out; this light is on when your TNC has an 
undelivered packet in it. Then change to the other antenna and try the 
same experiment. You might want to try it several times with each 
because the result can be effected by the amount of traffic on the 
frequency. If the retry rate is clearly lower with one antenna as 
compared to the other, that is likely the "better" one for you. 


You might also check to see how the retry rate compares at normal 
transmit power and the lowest transmit power available. This test tends 
to emphasize low signal strength conditions. 


3.F BASIC TNC PARAMETERS 


Most of the TNC parameters are convenience items. There are only a 
few which effect the performance of your packet station. We will focus 
on those in this section. 


3.F.1 MYCALL: You MUST set your call into the TNC. Usually when a 
TNC is brand new, the callsign is set to something like "NOCALL". Most 
nodes and other stations will not accept a connect request from 
NOCALL. You are also illegal because you are transmitting without 
identifying yourself! The TNC2 command is: cmd: mycall 

callsign. 


3.F.2 DIGIPEAT: You can specify whether or not other stations can use 
yours as a digipeater. It is normally allowed. If there is a reason why 
you don't want it used this way, the TNC2 command is cmd: digi off 


or cmd:digi on. 


3.F.3  DWAIT: This value is important primarily if you use other stations 
as digipeaters. It helps to keep your transmitter from sending one packet 
too soon after another which a digipeater may be resending. If you 
commonly use digis, try increasing this value. In TNC2s, the units you 
specify are in increments of .01 seconds (that is, 10 milliseconds). You 
might try setting DWAIT in this case around 0.5 seconds, or cmd: 
dwait 50. 


3.F.4 PACLEN: The PACLEN parameter controls the maximum length 
of your transmitted packets. Normally, this only comes into play if you 
type very long sentences without "returns" or "enters" at the right edge of 
the screen. When you type a number of characters (including spaces) 
equal to the PACLEN value, the TNC will automatically send a packet. 


You can often improve the retry rate if you make this value smaller when 
your signal is poor. It is also usually made fairly small on HF. There is a 
point of diminishing returns, however, because the header of every 
packet is about 25 characters. If you set PACLEN to 25 characters, the 
total length is really about 50. 


When conditions are very poor, you can achieve the same effect by 
making your lines short. If you press the enter key about mid-screen (on 
an 80 character screen), your packet length will be about 40 text 
characters (for a total length of about 65 characters). 


3.F.5 RETRY: This is the number of times your TNC tries to send a 
packet before it gives up. On a reasonably good frequency, a value of 4 
should be adequate. If you keep getting: 


*x* retry count exceeded 
***x DISCONNECTED 


then your retry value may be too small. This may be happening because 
the path between you and the other station is poor or because of other 
activity on the frequency (ie, hidden transmitters!) 


But also remember that when you raise the retry value, you are increasing 
the number of packets on the frequency which makes it harder for others 
who may increase THEIR retry values which makes it even harder for 
you, etc. 


3.F.6 TXDELAY: This is perhaps one of the most important performance 
parameters. This value determines how long your transmitter is turned 
on before the actual packet starts. Older radios often require longer 
TXDELAY. This is particularly true when the radio has a mechanical 
transmit/receive relay. If there is such a relay, you can often hear it 
"click" each time you transmit. For TNC2 type TNCs, the delay units are 
in steps of 10mS (that is, 0.01 seconds). A value of | gives 10ms, a 
value of 2 gives 20ms, etc. Most slow radios should be adequate with: 
cmd: TXD_ 60. Newer radios should be good with a value of 30 or less. 


It is important not to set this value longer than really necessary. A 150 
character packet (including header) takes a little over 0.125 seconds. If 
you make TXD a value of 60, the total time your transmitter is on for 
each packet is about 0.725 seconds. Thus, most of the "on" time is 
"warm-up" but it is still occupying the frequency. Thus, this time is 
really wasting the capacity of the frequency if it is not really necessary. 


3.F.7 SLOT TIME & PERSISTENCE: Many newer TNCs have a pair 
of parameters named slot time and persistence. Once the TNC detects 
that the frequency is not occupied by another transmitter and it has a 
packet to send, it waits a time interval of slot time. Then it generates a 
random number; if the random number is less than the persistence, it 
transmits; if the random number is greater than the persistence, it does 
not transmit. If it does not transmit, it waits another slot time and tries 
the random number again. 


In general, the random numbers fall in the range of 0 to 255. Thus, if 
you set persistence to 128, then, on average, it will transmit on one-half 
of the tries; if you set persistence to 64, it will transmit on one-quarter of 
the tries. If you operate on a busy frequency, choose smaller values for 
persistence; if 4 users is pretty common, try 64 but if 2 or fewer are the 
rule, then 128 is reasonable. The common rule is to choose a number 
which is about 256 divided by the average number of simultaneous users 
on the frequency. 


For information about other TNC parameters and how to set them, see 
section 4.G. 
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Once you have had a few conversations on packet and have started to 
find your way around your neighborhood network, many questions start 
to come up. 


Chapter 5 attempts to provide you with information about the basic idea 
of servers; though this name is not frequently used, what it represents 
pervades our system. Chapters 6, 7, 8 & 9 try to provide working 
information about bulletin boards, DX spotting, and network operation. 
Chapter 10 discusses some of the basics of AX.25. Detailed information 
about bulletin boards and nodes (networking) is found in Volume 2. 


In this chapter, we try to explore some of the more general operating 
questions which frequently come up. 


4.A OPERATING HINTS 


4.A.1 OPERATING POWER & RETRIES: FCC regulations require us 
to use the minimum power consistent with reliable com-munications. In 
the case of packet, reliable communication translates into low retry rate. 
Increasing power may reduce the number of retries your station takes to 
deliver a packet. But if the station at the other end requires many retries, 
you still have a problem. If the other station is a personal station, it may 
increase power, use a directional antenna, or use a digipeater. But if the 
station is a hilltop node, there isn't much that can be done at the that end. 
In this case, you may reduce retries on both ends with a directional 
antenna (and low power, all at the same time!) 


For poor link quality, some simple rules might help. Increasing your 
power (usually) decreases your outgoing retries but but have no effect 
on incoming retries. Higher gain antenna should decrease both incoming 
and outgoing retries. A properly aimed directional antenna should reduce 
incoming retries; it may reduce outgoing retries unless it makes you a 
hidden transmitter to other users. 


4.A.2 CHANGABLE PROPAGATION: Many areas experience seasonal 
and weather changes in VHF propagation. At the author's location, 
several nodes are available. The closest one (about 15 miles, line of 
sight) is quite variable, changing with weather and season; this may be 
partially attributable to relatively low power (a few watts). Another 
node, (about 30 miles, just out of line of sight) is quite reliable but, 
during heavy use times, is fraught with hidden transmitter problems. 
When you are unable to connect with your favorite node, don't 
immediately assume that it is a node problem. If your area is prone to 
fall temperature inversions (morning fog is a good indicator), this time is 
often especially difficult for propagation. 


Packet tends to be more sensitive to propagation than voice. While you 
may be able to understand a poor quality voice signal, packet is less 
tolerant. 


4.B KEYBOARD USE 


When you type, there are two very significant things to remember. The 
first has to do with packets sent to your TNC; the second has to do with 
compatibility with various computers. 


4.B.1 UNDOING WHAT HAS BEEN TYPED: Unless you change 
your TNC parameters, the send packet character is a carriage return 
(enter or return). Once this key has been pressed, the characters you 
have typed are formed into a packet and stored for sending. Unless you 
use a special cancel packet command (for TNC2s, see CANPAC ), what 
you have sent is forever beyond your control. You cannot fix errors, 
etc, after that point. What is done is done. 


Prior to the carriage return, you can backspace to your heart's delight, 
up to the first character following the preceding carriage return. 
Author's advice: hurrying or disliking the backspace key is no excuse for 
poor spelling! 


4.B.2 COMPATIBILTY WITH OTHER COMPUTERS: One of the 
dilemmas is how to keep what is typed compatible with other 

computers. There are few computers left with 40 character lines (the 
Apple II was one). There are many with 64 character lines 
(Commodore C64s among them). Displays with 80 character widths are 
common but not universal. So what do we do? 


If the other person uses a carriage return at the end of each line, you will 
see exactly what their screen width is. If you do the same, they will see 
yours. The strategy is for the one with the wider screen to use the 
carriage return at the same place on their screen as with the incoming 
packets. 


Not all computers recognize all of the characters which can be sent by 
other computers. A common character in this category is the TAB 
character. Unless two computers have the same TAB settings, text with 
TABs will come out strange on the other screen. The simple solution is 
to just avoid TAB! 


Also avoid relying on automatic line-wrap. Many terminal programs 
automatically insert carriage returns at the end of the screen, whether 
you press the key or not. Many others do not. Many terminal programs 
have problems with text containing very long lines (longer than 256 
characters, in particular). This is what happens when you rely on line 
wrap with a terminal program which does not insert carriage returns. 
For this reason and the others outlined above, please just use that 
enter/return key at the right-hand end of each line! 


See also Chapter 13, section A, for comments pertinent pre-typed text 
files. 


4.C THAT BLANKETY-BLANK "*** DISCONNECTED" 


When using very busy nodes or nodes which link on the same frequency 
as that the user frequency (see section 8.D), surprise disconnects can be 
quite frequent. There is one common cause and another less common 
cause. A disconnect happens when your station or the station at the 
other end has exceeded its retry limit for your connection. If the station 
at the other end (or somewhere else in a circuit of several nodes) retries 
out, you get: 


*** DISCONNECTED 


from your TNC. But if YOUR station retries out, you get: 


**x retry count exceeded 
*** DISCONNECTED 


The most common cause is the hidden transmitter situation (see section 
3.E.2). One of the problems is that it is quite difficult to tell when it is 
happening. See section 4.D for information which might let you know 
when it is happening. 


The less common cause is a change in propagation which causes the link 
to degrade. Possible, but very unlikely, causes are equipment failure at 
either end or accidental disconnect commands. 


4.D WHAT THE TNC MONITOR FUNCTION TELLS YOU 


The TNC's monitor capability can let you observe what is happening on 
your operating frequency. The monitor display can also be pretty 
confusing. And its format is not the same for all TNCs. To understand 
what is shown, it is necessary to look first at the several basic packet 


types. 


4.D.1 PACKET TYPES: There are about six basic packet types. Each 
serves a specific purpose. Connect (C) packets are used exclusively for 
connect requests; these are also known as SABM packets. Information 
(1) packets contain characters in the body of the packet. Unnumbered 
Information (UID) packets are sent out to nobody specific (as in CQs or 
beacons); these packets can also be thought of as Unconnected 
Information. UI packets are also the basic communication medium of 
TCP/IP (See Chapter 10). Disconnect" (DISC) packets are used 
exclusively for disconnect requests. Disconnected Mode (DM) packets 
are used to signal that a station is unable to accept a connect request. 
Unnumbered Acknowledge (UA) packets are used to acknowledge the 
receipt of either connect or disconnect requests. 


The packet types which tell the most about frequency congestion and 
retries are the RR, REJ and RNR packets. An RR packet (Receiver 
Ready) is used to signal the error-free receipt of a packet. An RR packet 
is in response to an I packet. I packets are numbered in the pattern 
0,1,2...,6,7,0,1,....; the RR packet indicates the number of the I packet 
is is acknowledging. 


RNR (Receiver Not Ready) packets are seen most often from nodes or 
bulletin boards. It means that the station cannot receive any more 
packets. The usual cause is that packets which must be sent on 
somewhere else have not been delivered. Thus, they are building up in 
the station and occupying memory (buffer) space. When the station has 


run out of space for that conversation, it sends an RNR; when it is able 
to accept more, it sends an RR. 


REJ (Reject) is sent when a packet has been received with an error. It is 
a request to resend the packet. The REJ packet contains the number of 
the I packet which had an error. 


4.D.2 CONGESTION SYMPTOMS: Congestion is easily seen because 
packets have both the TO and FROM callsigns in them. Hidden 
transmitters are particularly obvious when you see only one-half of a 
conversation (see 4.E because there is more than one reason for seeing 
only half of a conversation). When there are more than 6-8 stations on a 
single frequency, even if not hidden, collisions become significant. 


4.D.3 POOR LINK SYMPTOMS: Link quality is best observed during 
a light traffic time. If there are few other users on the frequency and 
both your station and the station you are in contact with require several 
retries per packet, the link is poor. Sometimes the excessive retry rate 
may be one-sided such as when one station has much more transmit 
power than the other. Retries can be seen by watching the PTT 
indicator on your TNC; every time it flashes after you press the 
enter/return key is a TRY. Expect one flash; more are retries. 


4.D.4 MONITOR DISPLAY: For starters, lets look at an example of a 
TNC2-style monitor display of a complete connect & disconnect 
process. 


cmd: c lyons 

cmd: *** CONNECTED to LYONS 

c 1 ka7upd 

KA7EHK-15>KA7UPD <C C P> 
KA7UPD>KA7EHK-15 <UA R F> 
KA7UPD>KA7EHK-15 <I C SO RO>:Mailbox ready 
LYONS: KA7UPD-1} Connected to KA7UPD 
KA7EHK-15>KA7UPD <RR R F R2> 

Mailbox ready 

Mailbox (B,H(elp),K,L,R,S) > 

b 

KA7EHK-15>KA7UPD <I C P SO R2>:b 
KA7UPD>KA7EHK-15 <D C P> 
KA7EHK-15>KA7UPD <UA R F> 

***x DISCONNECTED 


The first 2 lines show a connect to a node. The 3rd line is a connect 
request for G8BPQ style nodes. The 4th line is the connect request BY 
THE NODE on behalf of KA7EHK (see section 4.E for an explanation of 


the SSID change). The 5th line is an acceptance by KA7UPD of the 
connect request back to the node. This is followed immediately by the 
mailbox logon message by KA7UPD. Note that this is an I packet which 
is numbered RO. The next line is (finally) the notification by the node that 
the connect request was successful. The 8th line with the RR packet is 
an acknowledgement by the node of successful receipt of the preceding 
packet(s). The next 2 lines are the response from the KA7UPD mailbox 
as it actually comes out of KA7EHK's TNC. Note that there is one more 
line here than monitored between KA7UPD and the node. This packet 
was probably received with an error at the monitoring site and, thus, not 
shown. The next line is the bye command to KA7UPD's mailbox from 
KA7EHK. The I packet numbered R2 from the node (KA7EHK-15) to 
KA7UPD is the bye command being sent by the node to KA7UPD. That 
is followed by the disconnect (D) packet as sent by KA7UPD mailbox. 
That is, in turn, followed by the receipt acknowledgement for the 
disconnect by the node. The very last line shows the TNC's response to 
the disconnect from the node. 


Next, lets look at a situation where the other station is hidden: 


cmd:c valley 

cmd: *** CONNECTED to VALLEY 
c n7foft 
KA7VEHK-15>N7EGF <C C P> 

VALLEY:N7FGF-3} Connected to N7FGF 
KA7EHK-15>N7FGF <RR R F RI1> 

[AFA PK-88] 19096 free (A,B,H,J,K,L,R,S,V,?) > 
b 
KA7EHK-15>N7FGF <I C SO R1>:b 
KA7VEHK-15>N7FGF <UA R F> 

***x DISCONNECTED 


In the preceding case it all goes like the first example except that there 
are no monitored packets from N7FGF. There are two minor 
differences: (1) this is a TheNet node and the connect command is a 
little different than G8BPQ nodes, and (2) the mailbox response has only 
one line instead of two. 


What was just shown in the first two examples are nearly ideal packet 
transactions. Lets look at a little more normal situation. We will take 
this in sections to make it a bit simpler. Remember, however, that the 
next several boxes are part of a single monitoring log of only a few 
minutes duration. 


SALEM>N7TRJI <UA R F> 

SALEM>N7TRJI <UA R F> 

SALEM>N7TRJI <RR C P RO> 

N7TRJ <I C P SO RO>:Welcome to the Salem Packet 


Type for list of available commands. 
SALEM>N7TRJ <RR R F RI1> 
SALEM>N7TRJ <RR R F R2> 


From the previous examples, we can interpret these lines pretty easily. 
The first 2 lines are the node's response to N7TRJ's connect request. 
Finally, in line 4, the node logon message is sent. This is followed by 
RR packets acknowledging two packets from N7TRJ. We cannot tell 
what these packets are because N7TRJ is hidden from the monitoring 
site. 


SALEM>KB7NZ <UA R F> 

SALEM>KB7NZ <I C P SO RO>:Welcome to the Salem Packet 
Switch 
Type ? for list of available commands. 
SALEM>N7TRJ <RR R F R3> 


SALEM>KB7NZ <UA R F> 

SALEM>KB7NZ <RR C P RO> 

SALEM>N7TRJI <RR R F R4> 

SALEM>KB7NZ <RR R F RO> 

SALEM>KB7NZ <RR R F RI1> 

SALEM>KB7NZ <RR C P RI1> 

SALEM>KB7NZ <I C P SO R1>:Welcome to the Salem Packet 


Switch 
Type ? for list of available commands. 


In the midst of N7TRJ's node activities, now KB7NZ is making a 
connect request. This can be determined in line 1 because of the UA 
packet which is an acknowledgement of a connect request. This is 
immediately followed by the node logon message to KB7NZ. But not all 
is well with KB7NZ because a second connect acknowledge appears in 
line 5. This means that KB7NZ made a second connect request because 
the first acknowledge was not heard. Then, at the end, the logon 
message is sent again. Note that this time, it is numbered R1 while the 
first was RO. Note, also, that when several RR packets are sent to the 
same station with the same R number, it indicates that the station did not 
hear the earlier acknowledgement and resent the same packet, thus 
generating a new RR acknowledgement. 


SALEM>KB7NZ <I C P Sl R1>:SALEM:AF7S-1} Connected to 
SRABBS :N71IFJ 


SALEM>KB7NZ <I C P S2 R1>: [MSYS-1.12-HS] 


SALEM>KB7NZ <I C S3 R1>:Hello Bob, Welcome to N7IFJ's MSYS 
BBS in Salem, OR 


SALEM>KB7NZ <I C P S5 R1l>:Enter command: 
A,B,C,D,G,H,1,J3,K,L,M,N,P,R,S,1T,U,V,W,X 


12,* > 


KB7NZ sent the node a command to connect to SRABBS. We did not 
see that request, only notification of the connect. The connect has 
happened on another port (frequency) of the node and is not visible 
here. This is followed by the BBS logon message to KB7NZ. These 
packets are sent but we do not see KB7NZ's acknowledge-ment of each 
because that transmitter is hidden from the monitoring site. Also, there 
is a missing packet (S4) which was not shown because of errors in the 
received packet at the monitoring site. 


SALEM>N7TRJ <I C P Sl R4>:SALEM:AF7S-1} Connected to 
BEND :K7YLO-1 

SALEM>N7TRJ <RR R F R5> 

SALEM>KB7NZ <RR C P RI1> 


Now, in the first line, we see the node notify N7TRJ that a connect 
request to the distant node BEND is successful. It appears to be 
followed in the 3rd line with the acknowledgement of another packet 
from N7TRJ. 


SALEM>KD7YB <UA R F> 

SALEM>KD7YB <I C P SO RO>:Welcome to the Salem Packet 
Switch 

Type ? for list of available commands. 


SALEM>N7TRJ <RR C P R5> 

KD7YB>SALEM <RR R F RI1> 

SALEM>KD7YB <RR R F RI> 

SALEM>KD7YB <I C P Sl R1>:SALEM:AF7S-1} Connected to 
SRABBS :N7IFJ 


Here is yet a third connect request to the node, this time by KD7YB. 
And, like KB7NZ, a connection to SRABBS was requested. This time, 
however, KD7YB is not hidden from the monitoring site. 


KD7YB>SALEM <RR R F R2> 
SALEM>KD7YB <I C S3 R1>:Hello Joan, Welcome to N7IFJ's MSYS 


BBS in Salem, OR 
SALEM>KD7YB <I C S4 R1>:Use D HELP.DOC to download a help 
file (Tnx to KA7ZIN), enjoy. 


SALEM>N7TRJI <RR C P R5> 
KD7YB>SALEM <REJ R R2> 
SALEM>KB7NZ <RR R F R1> 
SALEM>KB7NZ <RR R F R2> 
SALEM>KD7YB <RR C P R1> 
SALEM>KD7YB <I C S2 R1>: [MSYS-1.12-HS] 


SALEM>KD7YB <I C S3 R1>:Hello Joan, Welcome to N7IFJ's MSYS 
BBS in Salem, OR 

SALEM>KD7YB <I C S4 R1>:Use D HELP.DOC to download a help 
file (Tnx to KA7ZIN), enjoy. 


SALEM>KD7YB <I C P S5 R1>:You have unread mail, please kill 
when read: 


SALEM>KB7NZ <RR C P R2> 

SALEM>KD7YB <I C P SO R1>:Enter command: 

A,B,C,D,G,H,1,J,K,L,M,N,P,R,S,1T,U,V,W,X 
?,* > 

red 


KD7YB>SALEM <RR R F RI1> 


The preceding group of monitored packets includes a REJ. This means 
that the node received a packet from KD7YB and that packet contained 
an error. The REJ packet is a request to resend the packet with the 
error. It is difficult from this point to associate which packet had the 
error and that is not so important to us anyway. It simply shows us 
how an error is shown. 


SALEM>KB7NZ <I C S3 R2>:Hello Bob, Welcome to N7IFJ's MSYS 
BBS in Salem, OR 


SALEM>KB7NZ <I C S4 R2>:Use D HELP.DOC to download a help 
file (Tnx to KA7ZIN), 
enjoy. 


SALEM>KB7NZ <I C S5 R2>:Enter command: 
A,B,C,D,G,H,1,J,K,L,M,N,P,R,S,T,U,V,W,X, ?, * > 


The preceding example does not really give a sense of the activity during 
the monitoring interval. This was observed over an interval of only a 
few minutes. And there were only three users present. Yet there were 
many packets passed! Among the three users, there were remarkably 
few retries. This is a very desirable condition but not that common 
when things are busy. 


4.E MORE ABOUT SSIDs 


There have already been 3 discussions concerning SSIDs (step 8 of 
"Setting Up the Modem" in section 2.E.1, section 3.A.1 and section 3.B). 
Here, the focus is on what happens to an SSID in a node. 


First, consider the SSID for your own station. When you set the TNC2 
parameter mycall callsign and just use your own call, a SSID of "0" is 
assumed. Other SSIDs for TNC2s is set with mycall callsign-SSID. 
For example, if NOAA wants an SSID of 5 for a TNC2, the entry would 
be mycall N9AA-S. 


When you use a Net/Rom-style networking node (which is the case 
throughout the west), the node adopts your call (modified) for all 
outgoing packets to anywhere other than your station. It puts an SSID 
on the call. The number it uses is 15-(your SSID). Thus, a node to 
which KA7EHK connects becomes to others KA7EH-15. KaNodes 
subtract 1 (MOD 16) from the SSID; an SSID coming in as 5 comes 
out 4 and one coming in as 0 goes out 15. 


But why all the monkey business with SSIDs? Suppose that you 
connect to your friendly local node and tell it to connect you to WOXYZ. 
Suppose, furthermore, that WOX YZ is not very far from you. The 
connect request is successful. What would happen if that SSID is not 
changed? Your TNC could not tell whether WOXYZ's packets are for 
the node or for you, directly. Since the node is (usually) your call with 
an SSID of 15, returning packets are addressed to that SSID and there is 
no confusion. 


There is a potential trap involving combinations of Net/Rom nodes and 
KaNodes. It has to do with the differing ways the two change incoming 
SSIDs into outgoing SSIDs. The author discovered this situation while 
exploring a local KANode. Suppose that you adopt an SSID of 0 and 
connect to a local KaNode. Then, on the SAME frequency, you connect 
to a Net/Rom-style node. The outgoing SSID from the KANode is 
0-1=15 and that is the incoming SSID at the Net/Rom node. If you then 
try to connect to another local station on the same port of the Net/Rom 
node as that on which you entered, you go out as SSID = 0. Now, the 
KANode can't distinguish between your packets and those from the 
Net/Rom node and a fearful lockup may ensue. There are several other 


combinations where the same result may occur. 


It is also worthwhile noting about SSIDs as packets go through a 
network of Net/Rom. Any time you autoroute to a neighboring node, 
you appear with the same SSID you would outgoing locally. It makes 
no difference how many nodes you pass through; the SSID stays the 
same. When you make an outgoing connect at a distant node, it is with 
the same SSID as it would be with a local connect. 


In section 4.D.2, it was mentioned that hearing a station with an SSID of 
15 but not hearing the call without an SSID is an indicator of a hidden 
transmitter. This is true. But there is also another reason for this to 
happen. Ifa station at a distant node has made a network connection to 
your node, then made a connection out to a local station, you will also 
see only the call with an SSID. The only way to tell which is the case is 
to connect to the node and obtain a User list (see Chapter 24 in Volume 2 
for more information). 


4.F OPERATING ON NODE FREQUENCIES 


After antennas, the next most common point of contention is about 
operating on the same frequency as an active node without using that 
node. As with most such debates, there are of course, at least two 
correct answers! 


4.F.1 ADVANTAGES OF OPERATING WITHOUT A NODE: If you 
do connect direct to another packet station (say a BBS) on a node 
frequency, you reduce the number of packets by 50%. Instead of one 
packet between you and the node and a second packet between the node 
and the other station, there is only one. Thus, your impact on the 
frequency is only half. 


An observation is in order: if you do choose to operate this way and it is 
possible for both stations to change frequencies, do so!. If 145.01MHz 
is ano-node frequency in your area, use it. This also appears to be a 
legitimate use of 145.50-145.80MHz for this is genuinely miscellaneous 
(this is an FCC set-aside no-repeater subband). Likewise, 
146.40-146.58MHz is simplex (ARRL Band Plan) and packet is, without 
any debate, simplex. Any of these frequencies away from normal packet 
operation could not help but go better than trying to compete with a node 
and its users! 


4.F.2 DISADVANTAGES OF OPERATING WITHOUT A NODE: One 
of the arguments against direct connects on a node frequency is that the 
node serves as traffic control on the frequency. Lets look at this 
argument and attempt to determine whether it is valid. 


Suppose that that there is a hilltop node called NODE. Two users, A & 
B, are on one side of the hill. Another user, C, is on the same side of 
the hillas A & B. Cis talking to D though NODE while A is talking to B 
directly. So, what happens? A,B,C, and NODE all hear each other; 
NODE and D hear each other. A, B, & C avoid collisions simply 
because they can sense each other's carriers. This happens without 
regard to the presence of NODE. D, on the other hand, collides with 
A,B, & C as heard by NODE (as well as the other way around) because 
they are hidden from each other. NODE is in a different situation; when 
it has a packet to send from D to C (or C to D), it waits its turn because 
it can hear all four. 


Now, suppose that A & B change their link so that NODE is used. Is it 
any better? The number of packets increases as pointed out in section 
4.F.1. The RR (acknowledgement) packets issued by NODE appears to 
modify the transmit pattern a little and reduce the collisions heard by 
NODE. But the effect does not seem to be large. 


Comment: it does appear that a small improvement in collision rate at the 
node does happen. There certainly are more packets on the frequency. 
If the collision rate is, indeed, reduced, there will be fewer retries but, 
again, the reduction seems small. Thus, it appears that the cost of 
operating on a node frequency without the node is not very high. But, 
why battle? Change frequency if possible! 


4.G TNC PARAMETERS 


TNCs have basically three sets of parameters. One set controls the radio 
operation of the TNC. One set controls the relationship between your 
terminal and the TNC. The last set controls the convenience features. 


In the following discussion based on TNC2 style commands, there is 
usuall a short and long version of each command. The short version is 
usually the first few letters of the long version. The short vesion may be 
used by itself; if the long version is used, it must be spelled correctly and 


in full. Most TNCs accept either upper or lower case letters in the 
commands. Commands will be denoted as XX[yyy] where XX is the 
required short form of the command and yyy is the optional remainder 
of the command. 


4.G.1 RADIO PARAMETERS: In TNC2 style, these are AXD[elay], 
AXH[ang], CH[eck], DW[ait], FR[ack], MAX[frame], MY{[call], 
P[aclen], RES[ptime], RE[try] & TX[delay]. With some newer TNCs 
which use somewhat different internal rules for timing retries, 
SLOT[time] and PER[sist] are also in this group of parameters. 


Unless you are using a voice repeater, AXD[elay] and AXH[ang] should 
be 0. AXD[elay] accounts for slow response time of most voice 
repeaters and AXH[ang] accounts for the usual voice repeater squelch 
tail. 


DW [ait] is used to account for characteristics of digipeaters but affects 
general operation also. For TNC2s the value of DW[ait] is in 10mS (10 
milliseconds or .0O1 seconds). A value of 1 produces a 10mS wait; a 
value of 15 produces a 150mS wait. This wait is between when the 
TNC detects a clear frequency and when it begins to transmit. 


TXD[elay] is used to control two aspects of operation. It, also, is a 
time interval. Also, in TNC2s, it is in units of 1OmS. On every 
transmission, when the transmitter is keyed, there is a wait until data 
sending actually begins. This is because some transmitters take much 
longer than others to establish normal operation when keyed. This 
parameter is also used to reduce collisions on retries. On retries, an 
extra delay is added to DW[ait]. This delay is a random amount. The 
idea is that if two transmissions collide, if they wait exactly the same 
interval for their retries, they will collide again. The extra delay is a 
random number times TXD[elay]; the random number varies on each 
retry from 0 to 15. Thus, after the first (unsuccessful) try, the wait 
might be DW[ait] + 7*TXD[elay]. The next time, it might be DW[ait] + 
3*TXD[elay]. Remember, this is the interval between sensing a clear 
frequency and transmitter keyup. There is still always a wait of 
TXD[elay] between transmitter keyup and start of data. 


FR[ack] controls how long the TNC waits for an acknowledgement 
before assuming that none is coming. In TNC2s, this is in units of 1 
second. When a digipeater is used, the wait time is lengthened according 
to the number of digis used (at the rate of 2 FR[ack] intervals per digi). 
If this value is set too small, your TNC will send retry packets when 


they are not needed. FR[ack] should generally be set quite a bit longer 
than RES[ptime]. 


RES[ptime] is the complement of FR[ack]. This is the MINIMUM wait 
time for packet acknowledgements. For TNC2s, this is in units of 
100mS (0.1 seconds). It comes into play primarily when many packets 
are being sent rapidly as in file transfers. 


P[aclen] sets the largest packet which your TNC will send. It has no 
effect on received packets. This value normally comes into effect only 
when you do not do enter/return at the right edge of the screen! 


MAX[frame] sets the number of unsent packets which are allowed to 
build up in your TNC. When this number is reached, the TNC does not 
accept any more characters from your terminal until there is room (if 
Flow is ON, the TNC2 default). MAX [frame] also sets the maximum 
number of packets which may be send it a continuous block. 


RE[try] sets the number of times your TNC will retry to send a packet 
before it gives up. Once this number of retries have been attempted, a 
disconnect request is sent. If you have a good path to the station you 
are talking with, this number can be fairly small (say 4). If the path is 
poor or the frequency is very busy, it may need increasing. Be aware, 
however, as your retries increase, it increases congestion and may cause 
others to increase their RE]try] value! The effect of this death-spiral 
should be apparent. 


CH]eck] sets the connection time-out interval. For TNC2,s the units are 
10 seconds. The default value for TNC2 is 30 for 300 seconds or 5 
minutes. If there has been no activity for this interval, your TNC sends 
a query packet to the other station. It retries according to the value for 
RE[try]. If no response is heard, a disconnect is sent. 


MY call] sets the callsign of your TNC. It is illegal to operate without 
your call entered into the TNC! The default value is NOCALL for 
TNC2s. Most nodes and other TNCs will not accept connect requests 
from NOCALL. If you suddenly find your connect requests being 
rejected, check your callsign! 


Check Chapter 3, section 3.F.7, for a discussion of slot time and 
persistance. 


It is easier to describe these parameters than to advise on proper 


settings. TXD]elay] depends primarily on the characteristics of your 
transmitter. FR[ack], DW[ait], and P[aclen] should be similar for all 
stations in your area. 


4.G.2 TERMINAL PARAMETERS: These parameters set the 
interaction between the TNC and your terminal. There is a lot of 
variation in these particular parameters from manufacturer to 
manufacturer. Fortunately, for most terminal programs, you do not 
have to change much because the defaults fit pretty well. Furthermore, 
most terminal programs are now flexible enough so that you can change 
the terminal configuration to fit the TNC rather than the other way 
around. 


Things you might particularly want to check if you are having problems 
are AUtolf, AWlen (sets number of data bits in characters), Echo, & 
PARity. 


It is the author's strong opinion that you should use the TNC's default 
terminal parameters and make the appropriate accomodation in the 
terminal. See section 4.M for the reason why. 


4.G.3 CONVENIENCE PARAMETERS: These include a great variety 
of things from monitor status to beacons. 


Some advice may be appropriate here. If you have a TNC with CWID 
(morse code identification), TURN IT OFF! The need for CWID has 
long passed. 


Beacons are another touchy subject. If you feel you must beacon, do it 
as infrequently as you can. For TNC2s, the beacon interval is in units of 
10 seconds up to 250 (2500 seconds). 2500 seconds is just over 40 
minutes. This interval is not too short! Also, if you must beacon, keep 
the text short. Otherwise, it just clutters the frequency. 


A pair of convenience parameters which the author likes are the TNC2 
NEW|[mode] and NO[mode]. If NO[mode] is off, the switching 
between command mode and converse mode is controlled by 

NEW [mode]; if it is on, switching between between command and 
converse modes happens only by direct command. I prefer NO[mode] 
off. NEW[mode] off causes the switch to converse mode from 
command mode to happen automatically every time a new connect 
occurs. Also, with NO[mode] off, the TNC stays in converse mode 
when a disconnect occurs. But with NEW[mode] on, the switch is 


automatic going both ways. 


The U[sers] command (TNC2) controls how many incoming 
connections are accepted by your TNC. Until you get some practice 
with handling several conversations at once, set this value to 1. This 
way, any multiple conversations must be initiated by you. 


4.H MAIL BOXES 


Several previous discussions have shown mailbox operation (see 
sections 3.B and 4.D.2). Here the focus will be on how your own 
mailbox operates (if you have one) and how to create one of you do not 
have one. 


4.H.1 TNC MAIL BOXES: TNC mailboxes reside within your TNC. 
They stay operating when your computer is turned off or used for 
non-packet activities. As previously mentioned concerning SSIDs 
(section 3.B), there are generally two classes of TNC mailboxes. One is 
the full-time mailbox and usually has a specific SSID assigned to it. The 
part-time mailbox uses the same SSID as you use but the mailbox cannot 
function when you are conversing through the TNC. 


With the exception of several newer TNCs with mail-snatch capability 
(that is, they can automatically connect to your local BBS and retrieve 
your mail), these TNCs take very little to set them up. The full-time 
mailboxes need an SSID assigned. You may also be able to set the 
connect message. In the case of part-time mail-boxes, you must 
remember to turn it on and off at the appropriate times. The author 
turns his on when packet operation ends and turns it back off (after 
checking for new mail) when packet operation resumes. 


Some TNCs have specific requirements to permit a mailbox to operate. 
For example, MFJ 1270/1274 TNCs require user 7 and the 
streamswitch set to stream A. 


4.H.2 SOFTWARE MAIL BOXES: software mailboxes reside in the 
terminal program. These range from NET/NOS at the high-end (see 
Chapter 14 and, in Volume 2, Chapter 25) to the popular LanLink (see 
Chapter 18 in Volume 2). Mailboxes for BayCom and DigiCom modems 
fall in this category, also. 


Software mailboxes are usually controlled by a script or config file. The 


writing of such a file is beyond the scope of this book. If the 
documentation is not adequate, you will have to rely on experience of 
other users. 


4.H.3 MAKING A MAILBOX: Ok, so you don't have a TNC with a 
built-in mailbox and you don't want to tie up a computer with one of the 
terminal programs which has a mailbox in it. What can be done to get 
the effect of a mailbox? Fortunately, its pretty easy. 


The strategy is this: there are flow-control commands which tell your 
TNC when it can send characters to the terminal. If you tell the TNC to 
stop sending, it simply stores characters in it memory until you tell it to 
begin again. This works so long as there are fewer characters to be 
stored than the capacity of the TNC memory! So, how do you use this? 


First, look up in the TNC manual under XON and XOFF. The 
character specified by XOFF tells the TNC to stop sending. The 
character specified by XON tells the TNC to start sending. For TNC2s, 
the defaults are XOFF = $13 (control-S) and XON= $11 (control-Q). 
Assuming that your TNC responds to TNC2 defaults, try the following 
experiment: 


(1) Send XOFF character (control-S) to your TNC. No carriage returns 
are needed; just send the single character. 


(2) Press the enter or return key 3 times. You should not see anything 
happen on the screen. 


(3) Send XON character (control-Q) to your TNC. No carriage returns 
are needed; just send the single character. 


(4) Three command prompts should appear on the screen after step 3. 
This is because those characters were stored in the TNC and were not 
released until you told the TNC that it is ok. 


If this experiment works, you have a rudimentary mailbox! To use it, 
compose a CTEXT to be used when you are not present. This is a 
message which is sent to anybody who connects when CMSG is ON. 

If CMSG is OFF, no CTEXT is sent to a connecting station. The author 
has used the following: 


CTEXT KA7EHK message buffer is open for your use; please 
leave msg 


When you end packet operation, simply send the following commands to 
your TNC: 


cmd: CMSG ON 
cmd: (xoff character) 


Then, when you resume packet operation, send the following. Note 
that there are no command prompts (cmd: ) because they have been held 
inside the TNC! 


CMSG OFF 
(xon character) 


Anything which the TNC received between the times XOFF was sent 
and XON was sent will come spilling out onto your computer screen! 
You now have a very simple mail box! You do need also to remember to 
leave your radio and TNC on; you computer may be off or devoted to 
other uses. 


4.1 THE TNC LIGHT SHOW 


Most stand-alone TNCs (with the exception of BayCom and DigiCom 
which really aren't TNCs) have a number of status lights on their front 
panel. These lights can provide some very useful indications of the 
activity of your packet station and of the frequency your radio is tuned 
to. 


4.1.1 POWER: the PWR indicator, if you have one, normally just sits 
there and glows. But if you are having problems, it is one of the first 
places to look. If it is not on, then power is missing. Check to see that 
the power cable for the TNC is still in place and that the main power 
supply or 115v connect is good. If these check out, then there may be 
more serious problems. 


4.1.2 CON: the CON light, if you have one, indicates that your TNC is 
connected to another station. It should go on as soon as you see a 
connected message on the screen; it should go out as soon as you see 
the disconnected message. 


The is a fairly significant but not obvious trap here. If you have a 
TNC2-clone (or similar), with multiple connect streams, the CON light 


shows the connect status of the stream you have currently selected. If 
there is no connection on that stream, the CON light will go out even 
though there are connects on other streams. 


TNC2s have a command called connect-status (CS) which lists the 
connection status of all the possible connection streams. It also shows 
which stream is the current one. This helps to resolve how many 
connections you have and who they are with. 


4.1.3 STA: the STA light indicates the status of outgoing packets. It 
stays lit as long as there is a packet waiting to be sent or one which has 
been sent but not acknowledged. Again, this light shows the status of 
the currently selected stream; even though all packets may have been 
delivered on other connections, it will stay lit if your current stream has 
an undelivered packet. Likewise, if all packets have been delivered on 
the current stream, it will go out even if there are undelivered packets on 
other streams. 


4.1.4 PTT: the PTT light (Push To Talk) goes on each time your 
transmitter is keyed. This is a useful indicator of proper connections 
between your TNC and transmitter. If the PTT light flashes but there is 
no transmit indication on the transmitter, there is a problem with the 
radio-to-TNC cable or connectors. 


The PTT light is an indicator which shows when your station is being 
used as a digipeater. If no connect light is on but the PTT light 
continues to flash, then your station is being used! It may also flash 
during a connect request before the actual connect is successful. 


4.1.5 DCD: the DCD (Data Carrier Detect) light is very useful. It lights 
when packets are detected on your frequency. It lights when ANY 
packets are detected, not just addressed to you. Thus, if it is flashing 
frequently, the frequency is quite busy. 


4.1.66 OTHER TNCs: Other TNCs may have different indicators than 
the ones discussed above. In particular, the Data Engine has a set which 


depends entirely on the installed software. They do not necessarily 
behave the same with JNOS40, G8BPQ, or other software. 


Look at the owner's manual for your TNC because these lights can tell 
you a lot about how your station is operating. It should also be noted 
that many of the multi-mode TNCs have many more indicators than 
discussed here; some show the current mode. Familiarise yourself with 


these because they can often tell you whats wrong when things are not 
right. 


4.J. The TNC Internal Clock 


The internal clock used by TNC2s for time marking (time stamping) has 
an interesting quirk. The folk-tale goes something like this: The TNC 
was designed around a particular clock crystal frequency. Baud rates 
were determined according to this frequency as well as the time clock. 
The software was all written and units built. It was only then that 
somebody noticed that a harmonic of the crystal frequency fell so close 
to one of the standard packet frequencies that it was nearly unusable. 
The fix for this problem was to tune it down slightly in frequency. 
There would be no real problem with baud rates because the change 
needed was quite small. But the change resulted in a clock which looses 
a few seconds (or more) each day. Thus, standard TNC2 clones need 
constant resetting of the time. 


4.K. Computer-TNC Baud Rates 


The real throughput of a TNC depends on the radio baud rate (and other 
things like DWAIT and retries). The on-screen display certainly looks 
nicer if there is a faster response between the TNC and the computer 
screen. 


TNC2s permit the computer baud rate to be set as high as 9600 baud. 
Most users who try this rate discover that characters are lost or garbled. 
The problem is the integrated circuit which is used to convert between 
computer logic levels and the voltages required for RS-232. It is an 
operational amplifier (op-amp) and the one used operates rather slowly. 
The specific integrated circuit is called a quad op-amp (that is, it 
contains four op-amps) and is an LM324. 


This op-amp may be replaced with a much faster TLO84. TLO84s are 
available at many hobby electronics shops where components are sold. 
Simply unplug the existing device and plug the new one in its place. 
Note the notch on one end of the original and put in the new one with 
the same orientation. In a standard TNC2, with the front toward you, 


this circuit is near the right side of the circuit board about mid-way 
back. 


4.L. Station Layout 


The actual layout of a station is more important than one might realize. 
This is because there are at least three devices in a packet station which 
can interfere with each other. The transmitter can interfere with TNC 
and computer operation. The TNC can interfere with receiver operation 
(as mentioned in section 4.J). The computer can interfere with receiver 
operation. 


Most of these problems are simplified if the station antenna is well 
separated from the station (30' or 10 meters is not too little). The worst 
situation is when you must use a small antenna very close to the TNC 
and computer. Transmitters can cause computers or TNCs to 
malfunction, and can cause video displays to wiggle. The author has 
seen and experienced many problems with antennas as close at 10' or 3 
meters to computers and TNCs. This is true whether operating on HF or 
VHF. 


When the antenna must be close to your other equipment (such as an 
emergency station or a portable one), careful choice of the computer is a 
must. Flat panel computer displays such as those used with laptop 
computers tend to be less affected by trans-mitters. Also, some 
computers are more quiet than others; experience of other hams may be 
an important guide. You may also need to add filtering capacitors at the 
TNC on the connector for the TNC-computer cable. Be particularly 
careful that all metal parts of the transceiver enclosure are connected 
together electrically. Special metal boxes for transceivers may also be 
necessary. 


4.M. When a TNC Quits 


Sooner or later, almost every packet operator comes face-to-face with a 
TNC which does not respond as it usually does. The author has had to 
deal with this situation several times. Here are some things which may 
help. 


4.M.1 Why IT Happens: It is actually rather difficult to say in every 
case why a TNC stops operating. Several of the author's cases seem to 
be associated with very fast power line drops and recoveries. Others 
have been quite mysterious. 


4.M.2 What Happens: One common effect is that the serial computer 
link settings get changed in the TNC. If the baud rate is set by switch, 
this seems pretty unlikely to change. But changes in parity, data bit, and 
stop bit settings have been observed. Other changes seem somewhat 
deeper than mere serial settings. 


4.M.3. What to Do?: The author's first step has usually been to try to 
re-establish serial communication between the TNC and the terminal. 


Step 1: First, try several return/enter. One of three things might happen. 
You might get no response at all. You might get a cmd: (or perhaps a 
scrambling of these characters). The TNC may try to send packets (as 
shown by the PTT indicator). If the latter case is true, the TNC is in 
CONVERSE mode; try a“*C to see if the command prompt shows. If 
you get a cmd: then you are close. If there is no response at all, you 
need to go on to the next step. 


If you get a cmd: or something close to this, try asking the TNC what its 
parity (PARity ) is; make certain that your terminal settings are the same. 
Then change the TNC parity back to what you want it to be first and 
second, change the terminal program to the same value. Do the same 
for number of data bits (AWLEN ). If neither of these work, go on to 
the next step. 


Step 2: Sometimes, what appears to be TNC failure is caused by the 
TNC being in an unexpected mode. These include KISS or HOST (the 
latter primarily in AEA or Kantronics TNCs). If your TNC is in either of 
these modes, it is unlikely that you you will be able to restore operation 
without resorting to the last step. But you cannot know whether or not 
this is true, so continue! 


Step 3: Another reason for unexpected TNC operation in multi-mode 
TNCs is caused by the TNC being placed into a communications mode 
(RTTY, CW, AMTOR, etc) which is different than the one you expect. 
If you have a multi-mode TNC, check with your manual about switching 
between communication modes. If your TNC is not multi-mode or if 
you are not successful, continue to the next step. 


Step 4: Try typing RESTART even if you get no other response on the 
screen. Returns the TNC to the same condition as if it were being 
turned on. If the faulty operation is due to a parameter (which is 
normally stored in the battery-backed memory) being changed, you may 
see no improvement. But, then again, sometimes it works. 


Step 5: Try turning off your TNC, then turn it back on. Again, there 
may be several responses. You may get the normal start-up message 
and all will be more-or-less normal. If this is the case, you may need to 
reset MYCALL and any other changes from default operation. The 
author keeps a card which lists these changes in the front of the TNC 
manual. 


You may get the normal startup message with some characters 
scrambled. In this case, the serial settings of the terminal are different 
than that of the TNC. Try changing these settings carefully, one at a 
time, until the message appears normal, then check to see whether other 
settings need to be changed. 


You may not get any response at all. If this is the case, go to the next 
step. 


Step 6: If you get no recognizable response when you turn on your 
TNC, something is improperly stored in the TNC's memory. The 
memory needs to be cleared of all of its old information so it can be 
restarted as if new. In a normally operating TNC, the RESET command 
will do this. Try typing out RESET because if the TNC recognizes it, it 
will save doing the next step. If it is successful, you will see the 
standard startup message. If it is not successful, proceed to the next 
step. 


Step 7: To clear the TNC memory, you need to understand that the TNC 
normally has a small battery in it to provide power for the memory when 
external power is turned off. You need to disrupt the battery power for 
a few minutes in order to clear the memory. Some TNCs (such as AEA 
PK-232s) have a jumper which forms a simple switch; this jumper can 
be removed to disrupt battery power; check with your manual to 
determine whether or not your TNC comes this way. Other TNCs have 
no jumper (as in MFJ 1270/1274). In this case, you need to break the 
circuit from the battery. These TNCs usually have a simple holder for 
the battery; you can slide a piece of paper under one of the battery 
spring clips to break the circuit. 


When the battery is disconnected, turn off the TNC and wait several 
minutes. Reconnect the battery and turn on the TNC. Normal operation 
should be restored. You will have to reset MYCALL and any other 
non-default TNC settings. 


The Amateur Packet Radio Handbook Chapter 5 


Copyright James Wagner, 1993 PACKET 
SERVERS 


Packet servers are special stations which you can connect to. These 
stations provide a "service". Some of these services are very simple and 
some are quite complex. This chapter discusses some of the more 
common servers and the basics of using them. Nodes, bulletin boards, 
and DX spotting are discussed in more detail in later chapters. Nodes 
and bulletin boards are discussed in great detail in Volume 2. 


5.A NODES 


5.A.1 MAKING A CONNECTION: A node is a station to which you can 
connect and ask it to connect you, in turn, to another station. In our 
telephone analogy, this service is like the old-time telephone operator. 
You rang the operator and asked to ring a telephone somewhere else. 
After the phone at the other end is answered, the central office becomes 
transparent. Even if the other phone is only a few blocks away, the 
signals go from your phone to the central office, and on to the other 
phone. 


A node works much the same way. You connect to a node and tell it: 
"Connect me to N7AAA." Once the connect is made, the node becomes 
transparent and you no longer talk to the node; instead, you talk to the 
other station. An example of this process is: 


cmd: c valley 

cmd:*** CONNECTED to VALLEY 

c_w/7exh 

VALLEY :N7FGF-3 } Failure with W/7EXH 

ec n7fof 

VALLEY:N7FGF-3} Connected to N7FGF 

[AFA PK-88] 19096 free (A,B,H,J,K,L,R,S,V,?) > 
cmd: d 

cmd:*** DISCONNECTED 


In this example, the local node "VALLEY" is connected to on lines 1 & 
2. Then, the node is asked to make a connection to W7EXH (line 3). 
The node tries a number of times and fails. Then, it notifies you that it 
was unable to satisfy your request (line 4). At this point, you are still 


connected to the node. A second request was made, this time to 
N7FGF; it was successful, but only got a mailbox. Finally, a disconnect 
was made as in the earlier examples. 


It is important to note that some users, particularly "old-timers" refer to 
nodes as "digis". Most nodes will serve as a digipeater but they also do 
much more. In this book, nodes are called nodes. 


5.A.2 AUTOROUTING: Many, but not all, nodes offer autorouting to 
other nodes. This function is rather like a primitive long distance phone 
call. Though the old-time phone system did not work exactly this way, 
it was close enough to pretend. Suppose that you wanted to call your 
Uncle Henry in New York City. You ring your local phone operator and 
say: "please connect me to the operator in New York City". After a 
substantial wait (while operators along the way make the necessary 
connections), you get the distant operator. Then you are able to say to 
the New York operator "Please ring Henry Jones at 4435 for me." You 
did not need to know how the telephone company lines are laid out; the 
operators manage that detail for you. 


Autorouting works much the same way. In this case, suppose that your 
friend N7AAA is on a (not too distant) node called PODUNK while you 
can directly connect to a node named METRO. After connecting to 
METRO, you simply tell it "Connect me to PODUNK". Once that 
happens, you are connected to PODUNK and you tell IT, "Connect me 
to N7AAA". It should be fairly obvious that you must know which node 
N7AAA is using. An example of how this works follows: 


cmd: c salem 

cmd:*** CONNECTED to SALEM 

Welcome to the Salem Packet Switch 

Type ? for list of available commands. 
c_mthood 

SALEM: AF7S-1} Connected to MTHOOD:KB7DBD-1 
Cc n7cpa 

MTHOOD:KB7DBD-1} Connected to N7CPA 

HI, TYPE <CTRL-T> FOR MENU, TYPE COMMAND "T" TO TALK TO 
N7CPA 

[ZCZ] *** LAN-LINK 2.00R> 

cmd: d 


cmd: *** DISCONNECTED 


In this example, a connection is made to the local node named "SALEM" 
in lines 1 &2. Then, the node is asked to connect to the node 
"MTHOOD" (line 5). SALEM notifies when it is successful in line 6. At 


this point, SALEM is transparent, and anything typed goes to MTHOOD. 
Next, MTHOOD is asked to connect to N7CPA in line 7. This is 
successful with the connect message shown. Finally, a disconnect is 
done. 


It is important to note that you do not need to know how the "network" 
is arranged between SALEM and MTHOOD. In fact, there is a 70cm 
link from SALEM to PDX7, a 1.25M link from PDX7 to WLINN, anda 
70cm link from WLINN to MTHOOD. But your packet is routed 
automatically. 


It is also important to note that not all nodes handle connect requests in 
exactly this way. Refer Chapters 8 & 9 for more information. 


5.B BULLETIN BOARDS 


Bulletin boards don't seem to have a direct analogy in the telephone 
system we have been using as an example. But if you have ever seen a 
bulletin board at a community location with cards, for sale ads, etc, you 
have seen something quite similar. 


Most (but not all) of the bulletin boards we are interested in are called 
"store-and-foreward" BBSs. This means that you may leave a message 
for a person somewhere else (even non-hams!); the message will be 
moved between neighboring bulletin boards to its destination. 


There are quite a variety of bulletin boards now in operation. Chapter 6 
discuss bulletin boards in more detail and Volume 2, Chapter 25 gives 
you operating details of each type I can find in use in the Northwest. 
There should be enough in this section to get you started. 


To use a bulletin board, you need to know four things: (1)which one to 
use, (2) how to reach it, (3) how to log on the first time, (4) how the 
basic operations work. 


5.A.1 FINDING A BBS: You can find out which one to use several 
ways. You can ask other packeteers on the node you prefer to use. 

You can look at the prompt list on your node to see if it has a "BBS 
server" attached. To get this, send the node a "?" (after connecting first, 
of course). A node with an attached BBS will return a prompt line 
something like this: 


c wlinn 


SALEM: AF7S-1} Connected to WLINN:WORLI-1 
2 


WLINN:WORLI-1} BBS RT QTH CONNECT BYE INFO NODES PORTS 
ROUTES USERS MHEARD 


The presence of the "BBS" in the prompt line shows that there is a BBS 
attached to the node. 


Many BBS's have their own "node names". The BBS attached to the 
WLINN node in the example above has the name "RLIMB" 
(interpretation: WORLI's MailBox). A node will give you a list of the 
other nodes it "knows" about if you send it an "N" (for Nodes). Names 
such as "xxxMB", "MBxxx", "xxxBOX, "BBSxxx", or "xxxBBS" are 
usually bulletin boards. 


Intelligent use of the network suggests that you use the BBS which is the 
closest to your "home" node, in the network sense. It makes little sense 
to use a BBS which is 4 or 5 nodes away when there is one 2 nodes 
away. The closer one usually has all the same bulletins on it. The BBS 
occupied the network getting those bulletins to it and you don't need to 
repeat what has already been done. 


If you cannot tell which is the closer BBS, ask a local node user. 


5.B.2 CONNECTING TO A BBS: Having chosen a BBS for a first try, 
how do you connect? From a network node, you may tell the node to 
connect you to anamed BBS. You may also connect to a node with an 
attached BBS and type "BBS"; the node will transfer you to the BBS. 
Some BBSs are not networking and must be connect to by callsign 
directly from its node. 


5.B.3 FIRST TIME LOGON: As a first time user, you will be asked a 
standard set of questions when you connect (log on) to the BBS. An 
example of what you will encounter is the following (edited slightly for 
brevity): 


CLARK:N7CHR-1} Connected to RFBBS:AA7RF 

[MSYS=1' .13-H8 ] 

Hello ?, Welcome to AA/7RF's MSYS BBS in Woodland, WA 
Welcome! As a new user you will see this information. Next 
time you connect you will go directly to the BBS command 
prompt. Please register as requested below. The home bbs 
you give must NOT be a personal (built into a TNC) BBS but 


rather a well known full service bbs that does mail 
forwarding. If you haven't picked a home bbs yet, you are 
welcome to use this one. Just enter its call with the NH 
command. 


Please use N command to enter your name 

Please use NQ command to enter your QTH (City and state) 
Please use NZ command to enter your Zip or Postal Code 
Please use NH command to enter call of BBS you want your 
mail sent to 

Enter command: A,B,C,D,G,H,1I,J,K,L,M,N,P,R,S,T,U,V,W,X, ?,* 
> 


Once you respond to these questions, you will be spared this first log-in 
ritual. The first-time logon procedure varies a little among various BBS 
types. Follow the instructions closely because they are intended for a 
first-time user. 


5.B.4 BBS BASIC SERVICES: Among all of the services which a 
bulletin board supplies, the most commonly used ones are (1) reading 
bulletins, (2) reading personal messages, and (3) sending personal 
messages. 


In most BBSs, an L[ist] will give you a list of all of the bulletins 
which have arrived at the BBS since you last checked in. With your first 
checkin, this list could be VERY long. Unless you specify otherwise 
(again, see Chapter 6 and Volume 2, Chapter 25), many BBSs will give 
you this list about 20 lines at a time. In this context, a "bulletin" is a 
message which can be read by anybody. 


If you find a bulletin with a subject which is interesting, note the 
message number (usually near the left end of the line in the message list). 
At the BBS prompt line, you may enter Riead]_### to read the 
message with number "###". 


Most BBSs notify you when you logon if you have waiting personal mail. 
If you are uncertain about your "mail", an LM (List Mine) will give you 
a list of all your mail. Your personal mail is numbered like the bulletins. 
And, like bulletins, you may read your mail with R[ead] ### at the BBS 
prompt; RM (Read Mine) will also read all personal messages 
addressed to you which you have not already read. 


It is your responsibility to dispose of your mail after it has been read. To 
do so, send K/ill]_### (Kill message ###). 


Many BBSs do not "remember" what you have read unless you 
disconnect by sending "B” (Bye) to the BBS. 


5.C CONVERSE SERVERS 


Converse servers are another answer to the question: "How do I find 
someone to talk to?" This is a little like a party line where everyone on 
the line is listening and anything said by any of the listeners is heard by 
all others. 


Converse servers have several names. One is "Round-Table", another is 
"CHAT node", a third is "CROWD node" . They come in several styles 
which are both similar and different. 


5.C.1 HOW CONVERSE SERVERS WORK: All of the servers 
provide a way where two or more packet stations can carry on a 
conversation. When you connect to it or otherwise activate it, all you 
type is sent to all other stations which are similarly connected. 
Depending on the implementation, you may direct comments to a 
particular participant. It is also often possible to specify information 
about your-self (such as name and QTH); this information is available to 
the other participants. 


5.C.2 AN EXAMPLE: 


SALEM: AF7S-—1 } Connected to WLINN:WORLI-1 
rt 
WLINN:WORLI-1} Connected to RT 


WORLI RoundTable Server V3.0 

Copyright (C) H. N. Oredson 1992 

Type /H for command summary. 

KA7EHK : *** Joined the RoundTable 

/H 

/U - Users 

/N - Enter Name 

/Q - Enter qth 

/B - Leave RoundTable and return to node. 


/Q Tangent, OR 
xxx Done 
/N Jim 


xxx Done 


/u 

Stations in the RoundTable are: 
2 KA7EHK [Jim, Tangent, OR] 

/B 

Returned to Node WLINN:WORLI-1 


This example is from one of several servers in the Portland, Oregon 
area. This one is entered by typing RT while connected to the node 
(line 2). When you have connected to the server, there is a "log-on 
message" which notifies you of the fact (lines 3 to 8). It also tells you 
how to get help. One of the common convention with these servers is 
that a line preceded by a / is directed to the server, rather than to the 
conversants. In the example, a name (line x) and QTH (line y) is 
specified. When asked who the current participants are (with /u near 
the end of the session), it indicates the call(s) (KA7EHK was the only 
participant this time), plus name and QTH if entered. Notice, also, that 
when you terminate the server with a /B (bye), you are left still 
connected to the node to which the server is attached (in this case). 


5.C.3 CONVERSE SERVER TYPES: There are 4 major converse 
server implementations. One (shown in the preceding example) is 
attached to certain nodes much like a BBS. You can determine whether 
or not there is such a server just like you can find if there is an attached 
BBS: send an ? to the node in order to get a prompt from the node. If 
you see "RT" on that list, there is one and you need only type RT to 
connect. An example of such a prompt line is this one: 


WLINN:WORLI-1} BBS RT QTH CONNECT BYE INFO NODES PORTS 
ROUTES USERS MHEARD 


A second server type is the "CHAT node" or "CROWD node". This 
type appears as a node to the packet network. With this type, most are 
named "CHAT". You must connect to it as if it were a node. Once 
done, it behaves much like the other converse servers. See Volume 2, 
Chapter 24, for a more detailed description of this combination node and 
converse server. 


Both of the preceding converse servers could be considered "local 
conversation". This is because servers are isolated from each other. 
The following two types are "distributed conversation" because servers 
may be linked together. 


DX Cluster stations usually contain a converse server. See section 5.F 
for an introduction to DX Spotting and Chapter 7 for a detailed 
description. It should suffice to say at this point that, except for 
command details, the operation is similar to that previously described. 
The principle difference is that users of linked DX Cluster stations can 
talk to each other as if they were all using a single server. 


NOS stations (including JNOS) have the capacity to implement a 
distributed converse system. The extreme case of this is the converse 
arrangement over Internet in which stations in Australia, Eastern Canada, 
Europe, and a number of U.S. sites can all talk together as if on a single 
server. See 14.J for some notes about NET and NOS; see Volume 2, 
Chapter 24, for details. 


5.D CALLBOOK SERVERS 


Callbook servers are a way of finding out basic information about the 
holders of U.S. amateur radio licenses. There are two styles of callbook 
servers which are available in the Northwest. One is the local server in 
which the information is available on a compact disk (CD) at the node 
site. This type can be found by, again, observing the node's prompt line: 


WLINN:WORLI-1} BBS RT QTH CONNECT BYE INFO 
NODES PORTS ROUTES USERS MHEARD 
qth ka7ehk 


JAMES D WAGNER KA7EHK 
31677 N LAKE CREEK DR 
TANGENT, OR 97389 
Born: 41 Class: T 


Returned to Node WLINN:WORLI-1 


With this type, one simply types "OTH callsign” asin line 3. The 
result is returned on several lines. 


Please be aware that these CDs are expensive and the station operator 
may not always purchase a new one every time one is available. Also be 
aware that these servers (usually) only list U.S. hams; some DX Spotting 
Systems have available U.S, Canadian, and some foreign calls. 


Many callbook servers also do other things like search for calls 
associated with a given name, or associated with a ZIP code. Ask the 


SYSOP for details if you want to use these other features. 


There is also the Internet callbook server. Through Internet Gateways, 
one may access a server on the U.S. East Coast. Ask the sysop of your 
local Internet Gateway for details. 


5.E INTERNET GATEWAYS 


Internet is an international computer network. It was originally designed 
to link major universities and government research laboratories. In 
recent years, the network has grown to include most universities and 
many "high-tech" businesses. Most universities with university-wide 
computer networks have "internets" on the campus with those nets 
linked to "the Internet". 


The KA9Q "NOS" program and its derivatives (including JNOS) provide 
a means for joining the packet radio network and various internets. 
When such an arrangement is made, the result is referred to as a 
"gateway". For detailed information about how this works, see Chapter 
14 and the JNOS entry in Volume 2, Chapter 24. 


5.F DX SPOTTING 


DX Spotting or "DX Clusters" are a special purpose packet network (at 
least, in the Northwest). These are nodes which are controlled by 
special software. The nodes are linked together so that most of what 
happens at each individual site is sent to all of the others. 


The purpose of this system is the location of DX stations. The features 
are specifically designed with this in mind. The new user should be 
aware that although these stations accept messages in the style of a 
store-and-foreward BBS, there is generally no interchange between the 
DX cluster system and the "regular" packet system in the Northwest. 
See Chapter 7 for details. 


5.G SUMMARY 


In this chapter, a variety of services provided by various packet 
installations have been discussed. The intention for this chapter was to 
provide enough information for new users so that there would be 
awareness of features of the packet radio system. 


For more information, refer to Chapter 6 about bulletin boards, Chapter 
7 about DX spotting nodes, Chapter 8, 9 & 10 about packet networking, 
Chapter 11 about the inner workings of packet protocols, Chapter 12 
about H.F. operation, Chapter 13 about packet satellites, Chapter 14 
about file transfers, & Chapter 15 about TCP/IP. 
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BOARDS 


Bulletin boards (BBSs) have become almost ubiquitous in our packet 
system. In this chapter, we will look at the basic method in which these 
operate. We will concentrate on the "store-and-forward" BBS; TNC 
"mailboxes", automatic mail programs such as LanLink, and DX spotting 
systems are discussed elsewhere. 


While bulletin boards have become widespread, not all packeteers are 
enthusiastic about them; in some cases, the feelings are very negative. 
The cause and effect of this situation will also be considered in this 
chapter. 


At the present time, all bulletin boards are full computers. Because of 
economic considerations, it does not seem practical to build a special 
purpose "bulletin board machine". Also, due to the human supervision 
generally required, it does not appear practical at the present time to 
locate a BBS on a remote hilltop. 


Where BBS commands are discussed, there are often two forms, a short 
and long form. Usually, the short form is made up of the first few 
characters of the long form. If the long form is used, it must be entered 
exactly, in full. These commands will be shown as XX/yyy] where XX 
is the short form and yyy are the optional additional characters to make 
the long form. Thus, the command L/ist] could be entered either as 
LIST or L_. Usually upper-case and lower-case characters are 
interchangable. 


6.A HOW A BULLETIN BOARD WORKS 


The primary use of bulletin boards is the receipt, movement, and delivery 
of messages and bulletins. We will use the term message to indicate 
something addressed to a specific individual; bulletin refers to something 
which can be read by anyone. Some other services may be provided but 
these represent the core function of a BBS. 


Every message deposited at a BBS with a Sfend] or SP (Send Personal) 
is given areference number. You specify to whom the message is to be 
sent by callsign. The BBS uses your callsign to indicate who sent the 


message. The BBS also attaches its call (and other information) to show 
where the message originated. 


Every time you log onto a BBS, the program reads through all of the 
messages. If it finds any addressed to you which have not been 
previously read, it notifies you. If there is no notification, then there are 
no unread messages. 


When a message is addressed to a user of the same BBS, the message 
remains for a time set by the BBS operator (SYSOP). If the message 
has not been read by that time, it may be erased. 


6.A.1 HIERARCHICAL ADDRESSING: When a message is addressed 
to somebody at another BBS, part of the addressing includes both the 
BBS callsign and its hierarchical address. The address includes the state, 
the country, and the continent. In this form, one of the Portland, 
Oregon-area BBSs might be specified as KB7 DBD.OR.USA.NA. 


The first part of the address is the two character abbreviation for state 
or province. In the US, the two letter postal state abbreviation is used. 
There is a separator (a period), followed by the country designator. 
The most common designators for those of us in North America are 
CAN (Canada), MEX (Mexico), and USA (United States). There is one 
more period separator followed by the continent designator. This is 
needed because there are duplicate country abbreviations on several 
continents (such as AUS for Austria and Australia). 


Some large states or states with many bulletin boards use additional 
address elements. For example, with California BBSs, there are 
addresses such as "N6AA.#NOCAL.CA.USA.NA". The letters preceded 
by the pound-sign (#) are commonly used as a regional designator with a 
state; sometimes it designates the nearest network node. 


6.A.2 LOCAL MESSAGE FORWARDING: Once a message has an 
address, how does it move? Bulletin boards automatically connect to 
each other through the packet network. If the destination is a BBS 
which is normally in direct contact with the one where it was sent, your 
BBS simply says to the other one (in effect) "I have a message for you. 
Can you accept it?" If the answer is "yes", it is transferred. The only 
difference between this message and one which stayed at the BBS is a 
forwarding record which shows where the message went. 


6.A.3 DISTANT FORWARDING: But what if the message is fora BBS 


which is not in direct contact with the one where the message 
originated? The SYSOP must create a forwarding file which tells which 
of its neighbors are sent messages for various destinations. For 
example, on the West Coast, a neighbor which does HF forwarding 
might be sent all messages for states east of the Mississippi River. The 
BBS simply scans its forwarding file and, (usually) based on the state 
designator in the hierarchical address, hands the message off to the 
appropriate neighbor. Thus, a BBS in Washington need not know the 
precise location of a BBS in North Carolina; it simply sends the message 
in the (hopefully appropriate) direction until it is close enough to be 
delivered. 


Each BBS though which the message passes adds its signature to the 
forwarding record attached to the message. This record tells where the 
message went and when. 


6.B MESSAGES 


As previously indicated, a message is something addressed to a specific 
individual. Lets look at the basics of message handling in somewhat 
more detail than in Chapter 5. 


6.B.1 LOG-ON NOTIFICATION: Every time you log onto a BBS, the 
program compares your call with the address of messages it holds. If 
there are any which you have not yet read, it notifies you. In general 
this notification looks something like this: 


SALEM:AF7S-1} Connected to SRABBS:N7IFJ 
[MSYS-1.12-H$] 
Hello Jim, Welcome to N7IFJ's MSYS BBS in Salem, OR 


You have unread mail, please kill when read: 

MSG # TR SIZE TO FROM @BBS DATE TITLE 

8559 PN 380 KA7EHK KB7IVK --- 930225 RE: Guide 
Enter command: A,B,C,D,G,H,1,J,K,L,M,N,P,R,S,T,U,V,W,X, ?,* 
> 


Observe the elements of this notification. The first item is the message 
number. Next comes message type; in this case PN means that it is a 
personal message which has not yet been read. The type becomes PY 
after being read. The next item is size in characters. Then comes the 
callsign of the person to whom the message is addressed. Following 
that is the callsign of the person who sent the message. Depending on 


the BBS style, the @BBS item may or may not show something here; in 
this case, there is an entry only if the message has not yet arrived at its 
destination. The date may be either the date it arrived at the destination 
or the date it was mailed. The final item is the subject as provided by the 
person who wrote the message. The format of this information may 
differ among BBS styles but, in general, all contain about the same 
information. 


6.B.2 READING MESSAGES: With almost all BBSs, R/ead] #### 
(where ##### is a number) will provide you with the text of the message 
of the number you specified. You will not be able to read messages 
addressed to others. Most BBSs allow you to read several messages in 
one "batch". The usual format is R/ead] ###1 ###2 ###3 (where ###1 
is the number of the first message, etc.) I usually limit such batches to 
4 messages or so if they are not too large (say 1000 characters or 
fewer). 


Many BBSs accept the command RM/ine] (ReadMine). This command 
usually gives you the text of all unread messages addressed to you. 


6.B.3 LISTING MESSAGES: Almost all BBSs recognize LM [ine] 
(ListMine) as the command to list all messages addressed to you, 
whether you have read them or not. In some cases, this list also 
includes messages you have sent. This list does not give you message 
text, only the basic information about the message. 


6.B.4 KILLING MESSAGES: Again, with almost all BBSs, K/ill] #### 
will kill (erase) message number ####. You cannot kill a message which 
you did not send or was not addressed to you. Unless there is a definite 
reason not to do so, please kill messages after you read them. They 
occupy disk space on the BBS computer and will stay there until the 
SYSOP's time limit runs out. 


6.B.5 VERBOSE READ: If you are interested in how a message 
arrived at your BBS, try a verbose read. In some programs, the 
command is RH #### (ReadHeaders) and in others, V #### (Verbose) 
This gives you the message with the forwarding log. Here is an 
example: 


rh_ 8629 
MSG # TR SIZE TO FROM @BBS DATE TITLE 
8629 PN 1125 KAVEHK N7HYD --~— 930227 CALLBOOK 


R:930227/0636z @:N7IFJ.#SALEM.OR.USA.NA Salem, OR 
R:930227/0339 3903@WORLI.OR.USA.NA 


R:930228/0306 3289@N7CHR. #VANC.WA.USA.NA 
R:930223/0447 O@N7UVH.#INW.ID.USA.NA 
R:930222/0637 8218@N7KOB.#INW.ID.USA.NA 


This message originated at the N7KQB BBS in Idaho & was handed off 
the next day to the N7UVH BBS in Idaho. Three days later, it was 
handed to the N7CHR BBS in Vancouver, WA. From there, it went to 
the WORLI BBS in Oregon and from there to the N7IFJ (destination) 
BBS in Salem, Oregon. 


6.B.6 AUTOMATIC REPLY: A recent addition to many BBS programs 
is the automatic reply feature. It copies the sender information from the 
message you specify. The program addresses a message from you back 
to that sender. In this way, you avoid errors in copying this information. 
The command varies with BBS. With some it is REPL #### to send a 
reply to message ####; with others it is SR #### (SendReply). 


6.B.7 HELP: All BBSs that I am aware of have some kind of help 
method. Almost universally, the ? tells you how to get help; H_ also 
usually works. In some cases H xxx (where xxx is the command you 
want to find out about) will tell you about that command. In other 
cases, it is 2xxx. The prompt line usually gives you a list of all of the 
basic commands which the program accepts. 


6.C BULLETINS 


Bulletins were previously defined as a message which can be read by any 
user of a BBS. 


6.C.1 LISTING BULLETINS: In general, the L/ist] command will list 
all of the bulletins which you have not read. Here is a common example 
of such a listing: 


L 

MSG # TR SIZE TO FROM @BBS DATE TITLE 

9412 BS 871 SALE KD7H PNW 930303 TEN TEC SALE 

9411 BS 630 ALL KB7PLE PNW 930303 SALE, ALINCO DJ160 
9407 BS 1422 ALL EB5SBUF WW 930303 IMFORMATION...? 

9404 BS 4329 AMSAT GM4IHJ WW 930303 Satgen205 SUN AND RADIO 
COMMS 

9403 BS 2767 SALE AA6ED PNW 930303 SALE: Sanyo 555 Computer 
9402 BS 1436 QST KT7H ARRL 930303 ARLBO22 FCC call sign 
update 

9401 BS 605 WANT KB6YZD ALLUSA 930303 Want Collins 75A4 


9400 BS 883 SALE N6WMK ALLUSA 930303 KENWOOD 440SAT, PS-50, 
SP-430 
9399 BS 672 WANT KA9UMJ ALLUSA 930303 Heath HW24 mobile mods 
wanted 
9398 BS 650 SALE KV6I1 ALLUSA 930303 ARGO 509+PWR SUPPLY+CW 
FILTER 
9397 BS 555 WANT KV61 ALLUSA 930303 BOONTON 260A Q METER 
9396 BS 1068 HELP N9MXT ALLUSA 930303 Info On 10meter Mobile 
Help 
9395 BS 800 ALL KF9AQ ALLUSA 930303 Need schem Motorola G41LLB 
9394 BS 748 WANT WE6A ALLUSA 930303 INFO & N.B. FOR ALDA 103 
9393 BS 1274 BINARY WD6EHR ALLUSA 930303 Binary files for ALL p1/4 


The listing shown here is but a small fraction of the actual list which 
was obtained. If it several days has passed since the last listing, it may 
be very long! 


Note that the information in this listing is very much like that contained 
in the message notification (see 6.B.1). There are two distinct 
differences. The first is under the type; here you see B$ which indicates 
that it is a bulletin. The second is in the TO column. This item is used 
to very roughly categorize the bulletin. The third is in the @BBS column. 
For bulletins, this item is used to specify distribution. This item is 
specified by the person who sent the bulletin. You should note that these 
vary from PNW to ALLUSA to WW (World Wide!). 


6.C.2 READING BULLETINS: The method is exactly like reading 
messages except that RM_ does not apply here. 


6.C.3 REPLYING TO BULLETINS: You may use the same automatic 
reply method which is used for personal messages. See section 6.B.6 
for more information. 


6.C.4 SENDING BULLETINS: Bulletins are sent just like messages 
except that you generally use SB to denote a bulletin. Instead of the 
callsign address for personal messages, pick a 6 character category it 
might fall in. Read bulletin lists to observe what sort of categories are 
being used. Instead of the destination BBS call, the entry should be a 
distribution category; if you don't put anything here, it will stay on the 
BBS where it is sent. 


PLEASE! Use the smallest distribution which makes sense for your 
message. Please read section 6.F.1, below, about bulletin addressing! 


For subject, try to choose a concise entry of about 35 or fewer 
characters including spaces. People decide whether or not to read a 


bulletin largely based on this. If it makes no sense, it won't be read! 


Keep the text of your bulletins concise. If you can keep it fewer than 
1000 characters (12 lines, 80 characters long), you will get more readers 
and fewer objections to its presence. 


6.D NTS TRAFFIC 


NTS refers to the National Traffic System, a arm of the American Radio 
Relay League (ARRL). One of the major NTS activities is the movement 
of third-party traffic. While much of this is done by CW and voice, 
digital modes including packet serve well. 


Because of the relative slowness of BBS forwarding, (when compared to 
some of the other traffic methods), packet is generally not used for 
relatively urgent messages. But packet does particularly well with lists 
which might be confusing in some other modes. 


You do not need to be an NTS person to originate or deliver NTS 
messages. Lets look at delivery first, then origination. 


6.D.1 DELIVERING NTS PACKET MESSAGES: These messages 
are not listed among bulletins. You must ask for a list. On most BBSs, 
LT lists traffic. The result (which should not be a surprise) looks a lot 
like lists of personal messages and bulletins: 


MSG # TR SIZE TO FROM G@BBS DATE TITLE 
9412 PT 871 97389 KD7H NTSOR 930303 503-928-TANGENT 
9411 PT 630 97301 KB7PLE NTSOR 930303 503-233-SALEM 


While the form should look familiar, what's in it is quite different. The 
entry under TO is the postal ZIP code of the addressee. The entry under 
@BBS is the NTS state designation; the two letter postal state 
abbreviation attached to NTS is used. The last part under title gives the 
telephone area code and telephone prefix. The latter is not required and 
not all messages will have it but it does make it easier to tell if the 
number is one you can call without a toll charge. 


If you decide that it is one which you want to try to deliver, try R ####; 
if the BBS won't do it, try RT #### (ReadTraffic message number) to 
read it. The message should follow the NTS message format which you 


will find in Chapter 23, (Volume 2). Try to deliver it quickly. When you 
are successful, go back to the BBS and KT #### (KillTraffic message 
number) to erase it. If you don't, somebody else may try to deliver the 
same message. 


6.D.2 ORIGINATING NTS PACKET MESSAGES: Originating a 
third-party message is just the reverse of delivering one. Use: 


ST 2222 @NTSXx 


where: ZZZZ is the postal ZIP code and xx is the two letter state 
abbreviation. 


When subject is requested, try to include the telephone & town 
information as shown in the previous section. 


For the text of the message, follow the standard NTS message format 
which is shown in Chapter 23, (Volume 2). 


6.E WHITEPAGES 


The WhitePages are an attempt to automatically route messages to 
individuals. When you log-on to a BBS for the first time (see Section 
5.B.3), the information which you enter may be sent to a regional 
WhitePages server. This server attempts to keep a listing (much like the 
telephone directory white pages). The results are distributed regularly to 
other BBSs in the area covered by this server. 


In general, the WhitePages process works well. There is, however, a 
rather drastic flaw in it. Suppose that you travel and take your packet 
equipment with you (yes, there are folks who do!) Suppose that your 
home BBS is in Seattle and you are in Chicago. You send a message to a 
friend back home. The person who receives the message attempts to 
answer you. But where does the message go? It goes where the 
WhitePages listing says you are supposed to be, not where you are. 


At present, there appears that little can be done about this in areas where 
this system is used other than to notify the normal home-BBS sysop of 
the new (temporary) location. Just don't be surprised if it happens to you 
or a friend. 


6.F COMMON CUSTOMS 


Most of the customs issues on bulletin boards concern bulletins. But 
whether message or bulletin, both are forms of amateur radio 
communication and fall within the regulatory limits set by the FCC. 


6.F.1 BULLETIN ADDRESSING: One of the most misused activities 
on BBSs is the ALL@USA or SALE@USA bulletins. Please think before 
you address a bulletin. Is it really important that it be distributed all over 
the country? There certainly some issues and items which warrant such 
addressing, but most do not! It may take several days or more for a 
bulletin to travel from one coast to another; most FOR SALE items are 
probably sold by the time the notice reaches the opposite coast. The 
resulting bulletins are just so much "trash" on the BBS! 


6.F.2 LIMITED BULLETIN ADDRESSES: There are bulletin addresses 
which are far more limited in scope that "@USA". You can use "@USW" 
for the Western U.S. You can use "@PNW'" for the Pacific Northwest. 
You can use "@ALLOR" for the state of Oregon (and there are similar 
designators for other states). There are even more localized addresses 
like "@PDX" (for Portland-area); again, there are probably similar 
designators in other metropolitan areas. Check with the SYSOP for these 
designators if you have any questions. 


6.F.3. OTHER CONSIDERATIONS: Some BBSs do not welcome for 
sale items. Please observe or ask if you have any questions. 


There are often other local "customary practices". Talk to others. If 
there is a problem with the customary practice, find out what is 
common with other BBSs in your area. If you don't like it, use another 
BBS. If you feel strongly about it, prepare a well-thought and persuasive 
argument... and use the bulletin process to present it to other users in 
your immediate area (but not to ALL@USA !!). 


6.G THE BBS & THE PACKET NETWORK 


After getting past the issue of ALL@USA and SALE@USA bulletins, the 
next most commonly voiced complaint is "how BBSs hurt our network!" 
Let's look at this concern and see how valid it is. 


It is not uncommon for a BBS with reasonable access to other BBSs 


which move regional bulletins to handle in excess of 100 bulletins per 
day. One observation suggests that bulletin sizes of about 1000 
characters may be about average. Depending on the local node 
parameters, such a bulletin would take 8 packets of 125 message 
characters (and another 50 header characters per packet). At 1200 baud, 
each packet occupies the network for 0.5 seconds or more, again 
depending on node parameters. In addition, there is transmitter key-up 
time ahead of the packet. With modern transceivers, this might be 
0.3seconds; with older, 0.5 seconds (see sections 3.F.3 and 4.G.1 for 
about DWait). Lets be charitable, then, and say that a packet takes about 
0.8 seconds, recognizing that it may be considerably longer. A short 
packet is required to ACK (acknowledge) each packet and make take 
another 0.05 to 0.1 seconds (plus DWAIT of 0.3 to 0.5 seconds). With 
zero retries, the 8 packets would thus occupy one link of the network 
for about 8.8 seconds. Packets, of course, are not sent without wait 
time between them so the actual time is again a little longer. Thus, our 
hypothetical 100 bulletins will take up 880 seconds or 14.7 minutes for 
each section of the network through which they pass. If the BBS 
forwards every bulletin received, that BBS is occupying the local 
network for about 30 minutes per day with bulletins. 


Now, if a BBS did not have to share the network with other users, 30 
minutes per day of "network loading" per day on account of bulletins is 
pretty small. But this is actually an unrealistically small value. 


Suppose that the local network is congested. Suppose that there are 
hidden transmitter nodes in portions of this network (See Chapters 8 & 9 
for discussions about networking). Then the retry rate goes up. It may 
go way up. If the network is congested and packets takes an average of 
4 tries to get through, 30 minutes becomes 2 hours. If the number of 
bulletins is larger, the loading time goes up also. And this still does not 
include message forwarding. 


If a BBS forwards during "prime time" (about 5PM local to about 8PM 
local), the impact is quite obvious. As a result, most BBSs schedule 
forwarding for off-peak times (especially Midnight to 6AM, local). 


This discussion, as sketchy as it is, should show the source of the 
conflict. Users get disconnected when a BBS hogs an inadequate 
network. There are at least three commonly used solutions to this 
problem. 


One solution is to fix the network. The view of some (including the 


author) is that if the network cannot support BBS forwarding, it is ill 
equipped to support other operations which also stress the network 
(such as emergencies). In this view, networks should be restructured so 
that there are only a few nodes on each frequency. The commonly 
stated guideline to maximize the capability of such networks is: no 
packet should leave a node on the same frequency as it came in on. This 
way, the retry rate is drastically reduced, the throughput goes up, and 
everybody is happier. 


Another solution is to increase the network baud rate. This solution also 
increases the throughput but only so long as links are good, the retry rate 
is relatively low to begin with, and appropriate equipment is used. 


Another solution is to have BBSs exchange packets on different 
frequencies than the regular network. The extreme version of this is to 
disallow BBS operation on segments of the network. This is the position 
taken by some node operators in scattered areas of the country; while 
the author may disagree with the philosophy behind viewpoint, I respect 
it. Node users should also. When the node information says no BBS use, 
please respect that request. 
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Section 5.F introduced the basic ideas of a DX spotting node. 
Examination of the characteristics of the DX nodes shows that each is a 
collection of servers. There is the core "Spotting Server" which is used 
to notify participants of DX station activity. In addition to that, there are 
other servers which carry out various functions. The presence or 
absence of these other servers depends on the particular software in use 
and the choice of the SYSOP. The spotting node software used as an 
example in this chapter is "PacketCluster" from Pavillion Software. 


The other servers include antenna azimuth determination for DX 
destinations, dissemination of propagation forecasts, "mailbox", local 
time determination at DX destinations, weather reports, data base 
management and access, callbook lookup, and conference services. 
While the command "syntax" may not emphasize this "collection of 
servers" aspect of DX Spotting Nodes, it is, none the less, there and 
important. 


It should also be pointed out that while these nodes are often networked 
together, a lot of work has been done to hide the fact from users. This 
is actually quite useful because it makes it easier to use. By and large, 
the users are folks who simply want to use packet radio as a tool for 
other interests. Thus, there is no obvious connecting from node to 
node. If you request callbook information from a server in the system 
which is not the one you are connected to, it happens whether or not 
you realize it is a distant node. It may be slower than your local node, 
but it still happens. 


The author's special thanks go to Larry Johnson, K7LJ, for a lot of help 
on this chapter. Larry is one of the organizers of the "NW DX Spotting 
System" which extends from Vancouver, British Columbia to Eugene, 
Oregon. 


One of the nodes in the NW DX Spotting system is used as an example 
for this chapter. DX-ers in other areas should be aware that this system 
is limited in its coverage. There are isolated (that is, not linked) spotting 
nodes scattered throughout the country as well as other networked 
systems. Some of these use the DX spotting facilities which are 
available in the MSYS node/BBS software; see Chapter 25 of Volume 2 
for some more details if this is the case in your area. There may be 
other spotting software in use. See Chapter 26 (in Volume 2) for an 
international DX Spotting Node List. That which is shown here appears 
to be used by all of the nodes in the Oregon-Washington-British 
Columbia system. 


7.A Use OF DX NODES 


The usual use of DX nodes is quite different than the normal packet 
system. Please recognize that this is written from the perspective of a 
non-user of the DX system! Here, the DX nodes are just another tool 
for making contacts with HF DX stations. 


The common way in which this system is used is that the local DX node 
is logged onto when HF operation starts. The connection is maintained 
during operation. Unlike the NetRom system, the DX nodes do not 
disconnect you after a period of inactivity. 


Some special TNC settings may be appropriate. The "Pavillion 
Software" Spotting Node shown in the following example uses 
"control-Y" for several purposes. TNC2s use “*Y for the default 
"CANcel PACket" command character. You can tell if this is the case 
with TNC2s by sending the TNC CANP [AC] (enter). If it responds 
with $19 (19 hex), then itis *Y. If this is the case, you should change 
your CANPAC. “A is suggested; again for TNC2s, the command is 
CANP [AC]_$01 to change it to *A. 


The "Pavillion Software" manual also indicates that your lines should be 
ended with a carriage return, only. TNC2s have a function LF [ADD] 
which adds a line-feed to each carriage return. Added line-feeds are 
rarely used now and you should make certain that it is off. Again, for 
TNC2s, the command is LF[ADD] OFF. 


When a DX station is reported by one of the users, all others who are 
connected (throughout the system) are notified. Users may specify that 


they wish only to be notified of certain call prefixes or groups of 
prefixes (called filtering). 


If basic terminal software is used, then this information appears on the 
screen. Many users have special software which compares data on QSL 
cards already in possession. Using this software, if a needed country is 
reported, the terminal program notifies with beeps, flashes, etc. One of 
the programs which does this is CT, a DX contest logging program. 


7.B LOGON 


Here is a logon example for N7AVK, the DX node located near Salem, 
Oregon. The software used by this node is the same as all of the other 
linked nodes in Western Oregon and Washington. The author had 
logged on previously and had indicated name, etc. The example is 
artificially divided, just to make it easier to discuss. The font size used in 
this text is smaller than normal to get the normal screen width on a 
printable page. 


7.B.1 INITIAL CONNECT: The initial connection goes like this. 


cmd: *** CONNECTED to N7AVK 

Hi Jim! You've been Digitalized to Mother-Cluster Node N7AVK 

ARRL Phone Test this Weekend... Make a Q..! 

Cluster: 4 nodes, 10 local/45 total users Max users 149 Uptime 3 16:58 
KA7EHK de N7AVK 5-Mar-1993 04572 Type H or ? for help > 


This logon messages tells you several pieces of information. First, there 
is the message of the day. This is followed by some very basic cluster 
information. In this case, there are 4 nodes which are currently linked. 
There are 10 users on this node and a total of 45 users presently in the 
system. Max Users appears to be the total number of different calls 
which have logged in since the node was reset; in this case, the last reset 
appears to have been 3 days, 16 hours and 58 minutes ago. 


7.B.2 NODE COMMANDS: The h[elp] command from the node 
gives this: 


ye 
PacketCluster (tm) V5.4 
(c) 1986-1992, Pavillion Software 


The available PacketCluster commands are: 
A,A/F,BYE, CONFER, DE,DI,DI/A,DI/0, DX, SH/DX, H,R, REP, S,S/P, SET, SH, T, TY, UPL, UPD, WWV, SH/ 
WWV, SH/WX 


ANNOUNCE <A> - Make a general announcement to local node <A> 

ANNOUNCE <A/F> - Make a general announcement to all nodes <A/F> 

BYE <B> - Bye, disconnect from the PacketCluster <BYE> 

CONFERENCE - Enter network conference mode <CONFER> 

DELETE <DE> - Delete mail message <DE MSG#> 

DIRECTORY <DI> - Show active mail messages <DI> 

DIRECTORY <DI/A> - Show All active mail messages <DI/A> 

DIRECTORY <DI/O> - Show mail to or from yourself <DI/0O> 

DX <DX> - Make a DX spotting info announcement <DX FREQ CALL> 

LIST <L> - Synonym for DIRECTORY <L> 

Show DX <SH/DX> - Show a DX spotting announcement <SH/DX> 

HELP or ? <H> - Help (displays this listing) <H> 

HELP command - Display help for a particular command <HELP SHOW> 

QUIT <Q> - Synonym for BYE <Q> 

READ <R> - Read a mail message <R MSG#> 

REPLY <REP> - Reply to the last-read mail message <REP MSG#> 

SEND <S> <S/P> - Send a private mail message <S CALL> or <S/P CALL> 

SET <SET> - Set user-specific parameters Example: <SET/Name Tim> 

SET/BEEP - Set Bells on or off <SET/NOBEEP> 

SET/DX - Set DX announcements <Default ON> OFF=<SET/NODX> 

SET/WWV - Set WWV announcements <Default ON> OFF=<SET/NOWWV> 

SET/ANN - Set Announcements <Default ON> OFF=<SET/NOANN> 

SET/MAIL - Set Mail announcements <Default ON> OFF=<SET/NOMAIL> 

SET/TALK - Set Talk feature <Default ON> OFF=<SET/NOTALK> 

SET/LOGIN - Set Login announcements <Default ON> OFF=<SET/NOLOGIN> 

SET/LOGOUT - Set Logout announcements <Default ON> OFF=<SET/NOLOGOUT> 

SET/FILTER - Filter any DXCC prefix <SET/FILTER/CW/BANDS=40,20 JA> 
- Filter command continued <SET/FILTER/SSB/BANDS=15,10 JA> 

SET/NOFILTER - Clear Filter settings <SET/NOFILTER/CW/BANDS=40, 20 JA> 

SHOW <SH/COM> - Display various PacketCluster Databases <SH/COMmands> 

SH/USERS - Display local Cluster users/Show all users<SH/USERS/FULL> 

SH/TIME Prefix - Show local times of any DXCC prefix <SH/TIME YI> 

SH/DX freql freq2- Display DX between frequency ranges <SH/DX 

14150-14200> 

SEND call - Send a message to a single station <SEND N6IXX> 

SEND call,call - Send a message to multiple stations <SEND N6IXX,W6GO, K6LLK> 

TALK <T> - Talk to specified station <T K6LLK> 

TYPE <TY> - Display a particular file Example: TY/BULLetin User.cmd 

UPDATE <UPD> - Update a database <UPD/Data> 

UPLOAD/FILE - Upload a general file <UPL/File> 

UPLOAD/BULLETIN - Upload a bulletin file <UPL/Bull> 

WWV <WWV> - Make a WWV announcement <WWV SF=xxx, A=xx, K=xx, Forecast> 

WWV <SH/WWV> - Show a WWV announcement <SH/WWV> 

WX <WX> - Make a Weather announcement <WX> 

SHOW WX <SH/WX> - Review recent weather announcements <SH/WX> 


KA7EHK de N7AVK 5-Mar 04592 > 


The first column gives a concise name for the command. In many 
cases, there is a second column with an entry such as <xx>; This is the 
short-hand command. The large column down the center gives a brief 


word description of the command. The last column gives an example of 
an actual entry. 


7.B.3 USERS: The sh/users/all command gives you a list of all 
of the current users of all of the Spotting Nodes (if several are linked). 
The sh/users command simply gives the list of the users on the node to 
which you are connected. Station calls in parenthesis, that is "()" have 
given their node a set/nohere command which means that they are 
connected but not available for conversations. Station calls with a "+" 
indicates that they are using the conference server. 


sh/users/all 
Stations currently connected to the PacketCluster Local node: (N7AVK) 
KC7EM (WR7D) (AB90) W7GUR W7EYE WA7UCJI 
W7QK (NOJO) (KAOEPR) K7RO N7BSB (W7XN) 
W721 AATEA K70Z K7LJ WA6SDR_ (N7PKB) 
AI7B AD7L KB7DA WB7SRW  (KO7N) (WJ7S) 
(W7IL) (WJ7R) (KB7IVU) (K7DBV) NK7L W7ZR 


WA7EQL N7CWR WK7Z K7UN W7RM KG7ZK 
KA7EHK 
KATEHK de N7AVK 5-Mar 07182 > 
sh/users 
Users connected to local PacketCluster node (N7AVK) 
KC7EM WA6SDR AI7B W7ZR WK7Z K7UN 
KA7EHK 
KATEHK de N7AVK 5-Mar 07192 > 


7.B.4 CONFIGURATION: The configuration list shows which nodes 
are currently networked with the one to which you are connected. This 
list tells you nothing about the physical layout of linked nodes. But it 
does show which nodes are currently in the system and which stations 
are current users of each node. The list of current users follows the 
conventions of the user list described in section 7.B.3. There is also a 
show/configuration/nodes which the author does not find vary 
useful. The basic configuration list looks like this: 


KA7EHK de N7AVK 3-Apr 22372 > 


sh/contig 
PacketCluster Configuration: 
Node Connected stations 
(N7AVK) W7AEP KC7EM WA6SDR W7ZR K7UN 
(AI7W) N6TR (KC7ET) AI7B N7NHR 
WK7Z N7MCA WA7GCS KA7EHK 
(WR7D) W7OK (AB90) W7EYE WB7SRW K7LJ 
KG7EV WA2TMP W7BG AATAX W7UZ 
W7GUR 
(NOJO) (KAOEPR) KB7DA W721 K7KIM W7XN 
K7RO K9JF (N7PKB) K7IFG KB7WW 
(N7JB) AATEA K70Z AD7L NK7L 
W7LI N7CWR W7 IMP KI7JA KI7FG 
KE7CX W7KJZ 
(NV6Z) (KY7X) W9ELB (KA7MCX) KATCSE WAORJY 
N6MZ W7LZP KF 7GH KQ40 WA7GMY 
WA7ECU K7LXC W7ND K7PVV (K7RIE) 
KI7EK KA7ZWO W7WA K7WTG W7WT 
NV6Z-9 N7IVM 
(WY7T) WB7RAL KB7GUH KD7IK KF7QZ 
(N7FSW) K7LZI K7UU N7EF N7LTF AATFET 
(W70M) NOAX K7DS W7JEN K70Q0 
K7RXV AATTC NX7K N7YQW 
(VE7CQD) (VE7CC) VE7IO (VE7FQN) WB7PMV KB7UG 
(VE7SOL) KA7AUH VE7CON VE7ADC N7RO 
VE7ON N7MC VE7AVM WB7PMU KB7TW 
VE7HDE W7KCZ VE7CQ (VE7IU) (WA7ZWG) 
KB7IGR KB7MSU W7EKM KI7X WB7CLU 
WB7WQE VETEW VE7SZ VE7NIN W7KCN 
WB7CAO (VE7VR) W7SFF VE7ASR VE7SV 
AATKE (VE7HNC) VE7AGC 
VE7GCE 
VETAV-5 
VE7PL 


KA7EHK de N7AVK 3-Apr 22372 > 


7.C DX SPOTTING SERVER 


DX spotting consists of two components. One is the immediate 
announcement and the other is data base information. 


7.C.1 IMMEDIATE ANNOUNCEMENT: The immediate 
announcement is sent by any user who wishes to 
make an announcement. The announcement is made 
with the command: 


DX_frequency callsign information. 


For example, if you wish to tell everyone that 9DIGIAA 
was just heard on 14020.0 (KHz) and that he said 
that he would be operating every day at O100Z, you 
might type DX 14020.0 9G1AA_every day at 0100Z.. 


Everyone else who is connected (as long as they did 
not SET/NODX or have their callsign filter set to ignore 


this call) would see the message. A typical set of 
announcements is like the following: 


KAT7EHK de N7AVK 11-Apr-1993 03572 Type H or ? for help > 
DX de KS7P: 7005.0 9GI1AA Wid lotsa lids on him! 04052 
DX de VETCC: 3795.0 W5IJU/KP1 up 3 04122 


7.C.2 NODX: If you do not want to see the DX announcements, you 
would type SET/NODX. If you have turned off the DX announcements 
and wish to turn them back on, you may type SET/DX. 


7.C.3 DX FILTERING: Filtering is a method of eliminating those 
announcements which are of no interest to you. It also reduces activity 
on the node frequency if you are going to ignore it anyway. The basic 


format is SET/FILTER mode/BAND= (x, xX,xX) DXCC-prefix(es). 


Valid numbers for bands are 160, 80, 40, 30, 20, 17, 15, 12, 10, 6, and 
2. These are (obviously) the meter designation for all of our operating 
bands from 160 meters to 2 meters. The word "ALL" may be used for 
both band and prefix. Valid entries for mode include CW and SSB; other 
modes such AM or FM are not recognized. Digital is recognized on the 
basis of frequency; PACKET,RTTTY, AMTOR are not distinguished. 

If a mode designation is left out, it is assumed to be CW/SSB. For 
example, if you want to filter out all activity on 2 meters, 6 meters, and 
10 meters, you could type 


SET/FILTER BAND=(2,10,6) ALL or 
SET/FILTER CW/SSB/BAND=(6,2,10) ALL 


Similarly, to filter out all JA, VE, VK on CW on 80 meters and 40 
meters, type 


SET/FILTER CW/BAND= (40,80) JA, VE, VK 


If you wish to clear a previously set filter, the command 
SET/NOFILTER may be used. 


7.C.4 CALLSIGN PREFIXES: One of the frequent puzzles for filter 
and other DX related commands is the recognized prefix which is 
appropriate for the command. You can find out using the command 
show/prefix prefix where prefix is your best guess. For 
example, most of us know that KL7 is Alaska (hardly DX). But under 
DXCC rules, it counts as a country. Here is what the show/prefix says 
about KL7: 


show/prefix KL7 
KL7 Alaska-Anchorage-KL7 CQ 01 ITU O1 
KL7 Alaska-Fairbanks-KL7 CQ 01 ITU O1 


KL7 Alaska-—Juneau-KL7 CO O01 ITU O1 
KL7 Alaska-—Nome-KL7 CO O01 ITU O1 
KAT7EHK de N7AVK 3-Apr 21102 > 


The preceding list shows how major cities in a country are designated 
with respect to prefixes. In an unfamiliar country, it helps to determine 
which is the prefix to use FOR DX SPOTTING LIST purposes. 


Similarly, for the prefix VP gives: 


VP2E Anguilla-VP2E CO 08 ITU 11 
VP2M Montserrat-—VP2M CQ 08 ITU 11 
VP2V Tortola-BVI-VP2V CO 08 ITU 11 
VP5 Turks-—Caicos-VP5 CQ 08 ITU 11 
VP8 So-Georgia-VP8/G CQ 13 ITU 73 
VP8 So-Orkney-VP8/0 CQO: 13> “LIU +3 
VP8 So-Sandwich-VP8/SA CQ 13 ITU 73 
VP8 So-Shetland-VP8/SH CQ 13 ITU 73 
VP8 Falkland-Is-VP8/F CQ 13 ITU 16 
VP8/F Falkland-Is-VP8/F CQ 13 ITU 16 
VP8/G So-Georgia-VP8/G CQ 13 ITU 73 
VP8/0 So-Orkney-VP8/0 CO: 13: ITU: 73 
VP8/SA So-Sandwich-VP8/SA CQ 13 ITU 73 
VP8/SH So-Shetland-VP8/SH CQ 13 ITU 73 
KA7VEHK de N7AVK 3-Apr 21062 > 


The latter list shows that VP8 applies to all of South Georgia, South 
Orkney, South Shetland, and the Falkland Islands. If you wish to 
specify a specific one of these, you would use, for example, VP8/F for 
Falkland Islands. 


The 3rd & 4th columns go together, indicating the CQ Magazine Worked 
All Zone zone number. The 5th and 6th columns likewise go together, 
indicating the ITU zone number. 


7.C.5 NEEDED COUNTRIES: When only a few countries are needed, 
it is much simpler to specify those few than all which are not needed. 


This is done with the SET/NEED_mode/BAND= (x, x, X) 
DXCC-prefix (es). Note that the format is essentially the same as 
FILTER. 


To clear a previously set need list, send SET/NONEED. 


7.C.6 DATA BASE: The DX data base is stored locally on each node. 
This is possible since all of the immediate DX announcements are sent to 
all nodes in a linked system. 


There are several commands to access this data base. The basic form is 
SH/DX. This command returns the most recent 10 reports. 


SH/DX 
7011.0 ON4ACG 30-Mar-1993 06032 <NX7K> 
7005.0 KP1/NF6S 30-Mar-1993 0557Z QSX UP <NX7K> 
7001.3 J52AG 30-Mar-1993 05552 <NX7K> 
14255.8 UI8QU 30-Mar-1993 0455Z OBL#185 QSL K9FD <W7EYE> 
14179.0 UI8ZAC 30-Mar-1993 04462 <W7EYE> 
14020.0 9GI1AA 30-Mar-1993 03502 UP 2/10 <N7TT> 
14194.5 W5SIJU/KP1 30-Mar-1993 03262 <N7TT> 
14020.0 9GI1AA 30-Mar-1993 03002 wkd @ 034.2 <K7LAY> 
14020.0 9GI1AA 30-Mar-1993 02442 Nw OSX 032.5 <W7HR> 
21020.0 9G1AA 30-Mar-1993 0220Z up <WA7BPI> 
KA7EHK de N7AVK 30-Mar 07262 > 


This list is pretty straight forward. First column is the frequency, The 
second is the call of the DX station. Next come the date and time 
reported. This is followed by and information column and the last is the 
call of the reporting station. 


It is possible to show quite a variety of combinations and selections from 
the DX data base. The next list is one which shows the reports over a 
specific frequency range; in this case, it is 21000 to 21999 KHz. 


SH/DX_ 21000-21999 


21020.0 9G1AA 30-Mar-1993 02202 up <WA7BPI> 
21267.0 ZD7SM 29-Mar-1993 2029%2 ...sri... <N71IXG> 
21267.0 ZD1SM 29-Mar-1993 2029%2 Maggie St. Helenia <N7IXG> 
21020.1 9G1AA 29-Mar-1993 2019Z2 up 2/10 <N7EF> 
21267.0 ZD7FM 29-Mar-1993 19552 maggie st helenia <KC7HS> 
21245.0 W5IJU/KP1 29-Mar-1993 19112 JA8RUZ OP <NN7L> 
21005.0 C91Jd 29-Mar-1993 18422 JOHN <W7KJJ> 
21293.2 9G1AA 29-Mar-1993 16312 <WA6SDR> 
21021.3 4HT1T 29-Mar-1993 15382 VIA SMOKCR <W7AM> 
2L021:..3- -STIT 29-Mar-1993 15332 VIA SMOKCR <W7AM> 
KAT7EHK de N7AVK 30-Mar 07282 > 


One may also search chronologically, by band, by prefix, by callsign 
fragment and by comment text. SHOW/DX/n lists the most recent "n" 
reports. By frequency range uses SHOW/DX/f1-f2 where fl and f2 
are the upper and lower frequency limits in kilohertz (in either order); the 
previous example used this form. The prefix form is used to show 
where (frequency) a given prefix has been most recently heard; the 


command is SHOWDX prefix where the prefix used is one of the 
prefixes from the SHOW/PREFIX list. For example, if one wants to 
find out where and when stations from the Pitcairn Island have been 
operating, one would send: 


show/dx vré 


10101.6 VR6BB 2-Apr-1993 04242 <N6MZ> 
14020.0 VR6BB 2-Apr-1993 01402 <K7LJ> 
14020.0 VR6BB 31-Mar-1993 03252 <W7KCN> 
10101.0 VR6BB 29-Mar-1993 04532 <N7JB> 
14020.0 VR6BB 29-Mar-1993 0137Z up 3 <K7DBV> 
14020.0 VR6BB 29-Mar-1993 0137Z qsx up 3 <K7DBV> 
28491.0 VR6Jd 28-Mar-1993 19532 <WX7R> 
28488.5 VR6Jd 28-Mar-1993 18142 <N7JB> 
14261.0 VR6BX 28-Mar-1993 0420Z brian <WA7GMY> 
28505.0 VR6Jd 26-Mar-1993 23202 <N7AVK> 
KA7EHK de N7AVK 3-Apr 22062 > 


The usefulness of this list should be self-evident if you are looking for a 
specific country! 


7.D CONFERENCE SERVER 


The DX Spotting Network conference server is not greatly different 
from other conference servers except that it is a distributed server. This 
means that a conference may be spread over several nodes in a linked 
system. 


Be aware that this server has several limitations. If several stations on 
the same node are in a conference, a packet must be sent to each 
participant. This may make the local user frequency quite busy. If 
users are on several different nodes, the throughput will drop if 
conference packets have to compete on the linking frequency with other 
packets. 


There are two conference modes. The first is the one-on-one or talk 
mode. The second is the conference mode. 


7.D.1 TALK MODE: The talk mode is directed to a single user on any of 
the nodes which are linked. You can find out who the current users are 
with the sh/users/all or sh/users commands (see section 
7.B.3). The command is simply T_ callsign. 


KAT7TEHK de N7AVK 30-Mar 0723Z > 
tkZun 


All further input will be sent to K7UN 
Exit talk mode by typing a ctrl/Z or /EXIT on a new line 


Don - are you there de KA7EHK 


will leave msg for you on SRABBS. Bye 
/EXIT 


Talk terminated 
KAT7EHK de N7AVK 30-Mar 07252 > 


This attempt was not particularly successful but it still demonstrates 
how TALK works. K7UN was on the user list, so the author sent ¢ 
k7un. The node then responds with the message that all which is typed 
will be sent to K7UN. Another line indicates how to exit from TALK 
mode. Two lines were typed with no response from K7UN. Then talk 
is ended with an EXIT command. The node then shows that your talk 
is, indeed finished. 


7.D.2 CONFERENCE MODE: There are two levels of conferencing 
mode. One is local (that is, limited to your local node) and the other is 
full (that is, extending to all other conference users on all linked nodes. 


confer 
**x* Entering local conference mode *** 
Exit conference mode by typing a ctrl/Z or /EXIT on a new line 


Jexit 

KA7EHK left the conference 
KA7EHK de N7AVK 3-Apr 2239Z > 
confer/full 


**x*x Entering cluster-wide conference mode *** 
Exit conference mode by typing a ctrl/Z or /EXIT on a new line 
anybody here? 


/exit 
KA7EHK left the conference 
KA7EHK de N7AVK 3-Apr 22402 > 


The first try was with the local conference server. Nobody else was 
using the conference (as observed with the user list, not shown this 
time). This simply shows how to enter and exit a conference. The 
second half enters the cluster-wide conference. Again, there were no 
other users and no response to the query. 


7.E MAIL SERVER 


The mail server works somewhat similarly to that of the 
"store-and-forward" BBSs described in Chapter 6. Be aware, however, 
that there are generally no cross-connections between the DX Spotting 
Network and the store-and-forward BBS system. Thus, a message 


addressed to someone who does not use the specific (linked) spotting 
system which you use WILL NOT BE DELIVERED! 


7.E.1 READING MESSAGES: If you have a waiting message, you will 
be notified when you log on to the spotting node. An example is this 
one: 


cmd: c n/7avk 

**x* CONNECTED to N7AVK 

Hi Jim! You've been Digitalized to Mother-Cluster Node N7AVK 
Cluster: 7 nodes, 16 local / 106 total users Max users 154 Uptime 
6 17:49 

You have the following new mail: 


Msg Size To From Date Time Subject 
286 200 KA7EHK N7AVK 1-Apr 05082 Re: MODE IN SET/FILTER 
KAT7EHK de N7AVK 3-Apr-1993 20582 Type H or ? for help > 


Similarly, if a message arrives while you are connected, a similar 
notification is sent to you. 


Messages may be read several ways. A simple read reads all 
messages addressed to you, starting with the oldest first. A read ### 
reads the message with the number specified. 


7.E.2 SENDING MESSAGES: The basic method of sending a 
message is the standard SEND callsign. When you do this, the node 
responds with a message number and a request for a message subject. 
Once the subject is entered, there is a prompt for the body of the 
message and information about how to end it. 


KA7EHK de N7AVK 3-Apr 21002 > 

s n/avk 

Message #325 Enter subject (29 characters) 

help? 

Enter text. Finish with ctrl/Z or /EXIT or cancel with ctrl/Y. 


Users should be aware that there are two classes of messages, private 
and non-private! It is possible for the Pavillion DX nodes to be set up so 
that messages are always private (unless specified otherwise) or are 
always non-private (unless specified otherwise). You may always 
specify a message to be private by using SEND/PRIVATE callsign. 
Any non-private message can be read by anyone. See section 7.E.5 for 
an example of a message & bulletin list containing both private and 
non-private messages. 


It is also possible to send a copy of a message to somebody else. The 
original may be one you originated or it may be one which was 
addressed to you. In either case, the command is SEND/COPY 


#tt?. callsign. 


A third method of sending a message is as a reply to a message sent to 
you. The reply is directed back to the station which sent the message to 
you. It applies to the message YOU JUST READ. The command is 


simply reply. 


7.E.3 LISTING YOUR MESSAGES: Messages which are addressed 
to you or where sent by you may be listed with the directory/own 
command. Here is what happens: 


KA7EHK de N7AVK 3-Apr 23302 > 
directory/own 
Msg Size To From Date Time Subject 
326 620 N7AVK KA7EHK 3-Apr 2136Z show/prefix 
325 447 N7AVK KA7EHK 3-Apr 2104Z Lew - 
286-p 200 KA7EHK N7AVK 1-Apr 0508Z Re: MODE IN SET/FILTER 
KA7EHK de N7AVK 3-Apr 23312 > 


7.E.4 DELETING MESSAGES: Once read, messages do not 
automatically disappear. You have to command each message to be 
deleted. 


delete 286 
Message 286 deleted 
KA7EHK de N7AVK 3-Apr 23322 > 


7.E.5 LISTING BULLETINS: Bulletins and non-private messages may 
be listed with the directory command. There are several common 
options. Section 7.E.3 showed how to use this command to list your 
own messages. The /new option lists all the (non-private or your own) 
messages and bulletins since you last used the directory command. The 
/all lists all active (non-private or your own) messages and bulletins. 
The /bulletins lists bulletins, only. 


directory/new 


Msg Size To From Date Time Subject 
326 620 N7AVK KA7EHK 3-Apr 2136Z show/prefix 
325 447 N7AVK KA7EHK 3-Apr 2104Z Lew - 
324 240 KA6V KB71IVU 3-Apr 19522 3c 
320 382 W6HCS KB7IRQ 3-Apr 0338Z OK, sounds good. Hope 
286-p 200 KA7EHK N7AVK 1-Apr 0508Z Re: MODE IN SET/FILTER 
269 381 N7SBI KC7HS 31-Mar 1459Z hello roy 


264 223 WANT WB7TGZ 31-Mar 0328Z ROHN "45" SECTIONS 
247 92 WANT AATUP 30-Mar 08222 rohn 25-g sections 
162 110 WANTED W7CQR 25-Mar 1537Z AEA Doctor-QSO 
142 Ly, FORSALE KO7N 24-Mar 1600Z HD CREATE RC5a-3 ROTOR 
141 66 FORSALE KO7N 24-Mar 1555Z KLM 40M-4 
140 71 FORSALE KO7N 24-Mar 1554Z KLM 20M-6 
129 135 LOCAL W7AM 23-Mar 0144Z DX LUNCH 
25 898 LOCAL AB9O 14-Mar 2240Z thanks for sh/qsl 
19 621 FORSALE W7ZR 11-Mar 23062 COMPUTER STUFF 
18 134. WANT WJ7S 11-Mar 0729Z XTALS FOR IC 22A 
16 348 KAT7CYA WX7R 11-Mar 0135Z hello tom! 
KAT7EHK de N7AVK 3-Apr 23272 > 


7.E.6 READING BULLETINS: Bulletins are read just like personal 
messages witha read _#### command. 


7.E.7 SENDING BULLETINS: Bulletins are sent just like messages. 
The only difference is how it is addressed. The directory list, above, 
gives an idea of how bulletins might be addressed. 


7.F TIME SERVER 


The time server shows the current local time and the time at DXCC 
prefix locations. 


KA7EHK de N/7AVK 4-Apr 00062 > 
show/time 
4-Apr-1993 00072 
KA7EHK de N/7AVK 4-Apr 0007Z > 
show/time vr6é 
VRO6 Pitcairn-Is-VR6 Local (standard) time 16:17 
KA7EHK de N7AVK 4-Apr 0007Z > 


The basic show/time gives the local UTC. The show/time_prefix 
shows the local time at the indicated prefix. Again, the recognized 
prefixes are those listed in the show/prefix command (see section 
7.C.4). 


Also related to the time server is sunrise and sunset information. The 
basic command is show/sun. Without any prefix, this command 
returns the local sunrise and sunset IF YOU HAVE GIVEN YOUR 
LATTITUDE/LONGITUDE with a set. location command. The 
show/sun prefix option gives the sunrise and sunset at the prefix 
specified in terms of UTC. 


show/sun 


**x*x No prefix specified and no location information for you was found 
K*kK*K 


KA7EHK de N/7AVK 4-Apr 00082 > 
show/sun vré 
VRO6 Pitcairn-Is-VR6 Sunrise: 14502 Sunset: 02362 


7.G HEADING SERVER 


The standard command to obtain the heading to a prefix location is 
SHOW/HEADING prefix. The short great-circle route is given as the 
primary heading and the long great-circle route is given as the reciprocal 
heading. 


KA7EHK de N7AVK 4-Apr 00082 > 

show/heading vr6é 

VR6 Pitcairn-Is-VR6: 187 degs - dist: 4848 mi, 7801 km Reciprocal 
heading: 5 degs 

KA7EHK de N7AVK 4-Apr 0009Z > 


7.H WWV SERVER 


7.H.1 WWV DATA BASE: The WWYV server displays WWV 
propagation information which has been entered by users. This 
information includes the date and time of the announcement, the three 
index numbers which WWV broadcasts, and the descriptive forecast. 
The meaning of the indices and descriptive forecast are given in 
magazine articles about propagation forecasting and in the ARRL 
Handbook. A typical example is: 


show/wwv 
Date Hour SFI A K Forecast 
4-Apr-1993 00 117 #1 #41 dow, quiet !!!!! <VE7CQD> 
3-Apr-1993 21 147 2 QO SA LOW, GMF QUIET <W7GUR> 
3-Apr-1993 18 121 5 0 low/quiet <N6MZ> 
3-Apr-1993 15 121 5 2 Low / Quiet <N7VZF> 
3-Apr-1993 00 121 5 2 low, quiet <KA7MCX> 
2-Apr-1993 21 121 4 1 SA LOW, GMF QUIET <W7GUR> 
2-Apr-1993 18 124 8 0 low, quiet <KA7MCX> 
2-Apr-1993 15 124 8 1 low/quiet-unset <N6MZ> 
2-Apr-1993 12 124 8 2 low/quiet-unset <N6MZ> 
2-Apr-1993 03 124 8 2 low, quiet to unsettled <KA7MCX> 


KAT7EHK de N7AVK 4-Apr 01252 > 


7.H.2 WWV ANNOUNCEMENTS: Each time a WWV announcement is 
made, it also appears along with the DX announcements unless you have 
disabled these announcements with the command 

set /nowwv_announcements. The WWV announcement turnoff 
may be turned back on with set /wwv_announcements. An example 
of a WWV announcement is: 


KA7EHK de N7AVK 4-Apr 0009Z > 

DX de WK7Z: 14030.0 A71CW WORKING SEVENS 00222 
DX de W7OF: 14196.5 4NSET LOUD 00192 
DX de N7IXG: 21295.0 9G1AA werking simplex by ###'s 00522 
WWV de VE7CQD <0O0O> : SFI=117, A= 1, K= 1, low, quiet !!!!! 


7.H.3 MAKING A WWV ANNOUNCMENT: WWYV announcements 
may be made by anyone who hears WWV broadcasts. The format is 


wWwV SF=xxx, A=yy, K=zz, forecast. You simply type out this 
message and replace the xxx, etc with the numbers from the broadcast. 


7.H.4 MUF INFORMATION: A byproduct of the WWV information is 
the ability to compute MUF (Maximum Usable Frequency) for the path 
to a specified location (ie, prefix). The command is of the form 
show/MUF prefix. Another example for Pitcairn Island is: 


KA7EHK de N7AVK 4-Apr 01252 > 

show/muf vr6é 

Pitcairn-Is-VR6 Propagation: Flux: 117 Sunspots: 67 Rad Angle: 7 
Dist: 7800 km Hops: 3 MUF (90%):18.4 (50%):21.7 (10%):26.5 
KA7EHK de N7AVK 4-Apr 03012 > 


The MUF figure given is in MHz for the path to the specified destination. 
The preceding example says that the MUF will be at least 18.4MHz 90% 
of the time, it will be as high as 21.7MHz 50% of the time, and it will be 
as high as 26.5MHz 10% of the time. 


7.1 DATA BASE SERVER 


The Pavillion DX Spotting Node software has the ability to function as a 
distributed data base and as a server to that data base. Earlier sections of 
this chapter have already considered some functions which really are 
aspects of data base service. These include show/prefix, show/wwv, 
and show/dx. A few will be described in later sections of this chapter. 


7.1.1 DATA BASE LIST: The data bases which are available are listed 
with the simple show command: 


show/commands 
HOW/OBLAST 
HOW/WVDXC 
HOW/CLUB 
HOW / BUREAU 
HOW/F LUX 
HOW/ ZONE 
HOW/CONTEST 
HOW/QSL 
HOW/OSLNEW 
HOW/IRC 
HOW/RULES 
HOW/ALLOC 
HOW/HELP 
HOW /DXNODES 
HOW/DEALER 
OW/DXCC 
HOW / BAND 
HOW/FCC 
HOW/OPINFO 
HOW/ COORD 
HOW/IOTA 
HOW/ TODAY 
HOW/PUB 
HOW/ COUNTY 
HOW/ LADDER 
HOW/QSLREC 
HOW/BUCKMASTER 
HOW/MIC 
HOW/ SCORES 

A7EHK de N7AVK 4-Apr 0519Z > 


RNA NN NNN NNN NN NN NNN NNNNNNNNNNNNN 
I 


This list really contains recognized show commands for data base 
access. If you enter any of the above commands, the response will first 
tell you if it is accessing a remote data base. Then there is a short 
answer if the data base is present. This answer tells you how to obtain 
the information which is stored within the data base. Many of the data 
bases listed above appear to be third-party data bases; that is, they were 
assembled by a person somewhere else and distributed to DX Spotting 
Node SYSOPS. It is quite likely that not all of these are available on all 
systems or that the list above contains all of the possible data bases. It is 
also likely that this list will change over time. 


7.1.2 DATA BASE SUMMARIES: For those data bases listed above 
which are actually present, here are the access summaries. Note that in 
the portion of the DX Spotting System which is near the author 
(northwest Oregon), the data bases are distributed on at least four other 


nodes. It is likely that other sections of the network have their own data 
bases to reduce data base message activity on portions of the network 
which join major metropolitan areas. Data bases which are absent are 
not included 


KA7EHK de N7AVK 4-Apr 0519Z > 

show/oblast 

The SHOW/OBLAST command is used to provide the oblast number, CQ zone 
and ITU zone for a specified Russian prefix. 


For UVA1,2,3,4,6,8,9,0, use the number in the call, e.g., 
SHOW/OBLAST UA3N 

For others, use a hyphen instead of the number, e.g., 
SHOW/OBLAST UH-W 


You may also enter a number to get the oblast name and prefix: 
SHOW/OBLAST 111. 


(Please report any corrections to and provided by K1KI) 
7/2/89 


Note that oblasts are Russian political subdivisions (like counties?) 


KATEHK de N7AVK 4-Apr 05282 > 

show/wvdxc 

Accessing remote database on NOJO...standby... 
KA7EHK de N7AVK 4-Apr 0529Z > 


The SHOW/WVDXC command is used to provide info on the WVDXC 
members. 


To access info on the WVDXC members type SHOW/WVDXC Call 
Replace 'Call' with the call of the club member you are requesting 
info on. 


To update your file in SH/WVDXC use the UPDATE/WVDXC command. 
? UPDATE - For additional info on update command. 
? UPDATE/APPEND - For info on how to add more to ur file. 


You will only be allowed to update your own file. Anyone is welcome. 


Note that WVDXC is the Willamette Valley DX Club. Thus, this file, if 
present, will have the name or abbreviation of a local DX club. 


KA7EHK de N7AVK 4-Apr 05332 > 

show/qsl 

Accessing remote database on WR7D...standby... 
KA7EHK de N7AVK 4-Apr 05332 > 


QSL lookup data from the W6GO/K6HHD QSL Manager List may be obtained 
by typing <SHOW/QSL call>, where call is the callsign of the DX 
station you wish to look up. This database is provided asa 
service to the W6GO/K6HHD QSL Manager List subscribers who use this 
Packet Cluster. If a local QSL database is present and the callsign 
you have requested is present in the local database, the local 
database information will be sent to you before the information from 
the W6GO/K6HHD QSL Manager list. 


KA7EHK de N7AVK 4-Apr 0534Z > 
show/qslnew 


Accessing remote database on WR7D...standby... 

KA7EHK de N7AVK 4-Apr 0534Z > 

Please place new QSL information into QSLNEW. QSLNEW is a database 
which you create. It is searched in addition to the W6GO/K6HHD QSL 
Manager list whenever you ask for a QSL route. To add or correct a 


QSL route, please TYPE UPDATE/QSL and enter the data as prompted. 
When you have completed your entry, on a new line type /EXIT<ENTER> 
or <CTRL-Z><ENTER>. 

If you wish to add information to what is already in QSLNEW, you may 
append additional data to an existing entry by typing 
UPDATE/QSLNEW/APPEND rather than typing UPDATE/QSLNEW. 


Your SYSOP will forward this information monthly for use in updating 


the QSL database. 73 de W6GO and K6HHD. 14-Dec-90 W6GO 
KAT7EHK de N7AVK 4-Apr 05362 > 

show/rules 

Accessing remote database on NOJO...standby... 

KAT7EHK de N7AVK 4-Apr 05382 > 


The SHow/RULES command is used to display sections of FCC Rules and 
Regulations, Part 97, covering the Amateur Radio Service, and sources 
for information on FCC Rules and Regulations publications. [12/31/91] 


SH/RULES [sect #] to read a Section number Ex: SH/RULES 97.115 


SH/RULES INDEX to list Subparts/Sections 
SH/RULES PUB to list Rule publications 
SH/RULES AUTHOR to provide comments, corrections, updates 
KAT7EHK de N7AVK 4-Apr 05392 > 
show/alloc 
Accessing remote database on NOJO...standby... 
KAT7EHK de N7AVK 4-Apr 0539Z > 


The SHOW/ALLOCATION command is used to obtain the country which is 
allocated the specified ITU prefix block. The qualifier should be 

a two character prefix. Valid characters are A-Z and 0-9 (two numbers 
are not valid). If a single valid character is entered, all allocated 
blocks for the character will be displayed. 


Syntax: SHow/ALlocation xx or x 


This database was provided by K3ARV of the Melbourne, FL 
PacketCluster node. 


Please send updates and corrections to K3ARV. Distributed by 
W6GO/K6HHD 
KAT7EHK de N7AVK 4-Apr 05412 > 


sh/help 


Accessing remote database on NOJO...standby... 

KAT7EHK de N7AVK 4-Apr 05412 > 

The SHOW/HELP [file] will provide some system and operating tips 
on using the DX PacketCluster network. Most of these files have 
been messages previously uploaded by K6PBT and now contained in a 
database. If you have any comments or suggestions that you think 
would be of help to other users in using this network, please send 
them to K6PBT to be added to this HELP database. 

SH/HELP [file]; files are: CONNECTED, CANCEL, TIPS, COMMANDS, 
NETWORK, 

TNC and NEWUSER. 


KAT7EHK de N7AVK 4-Apr 05422 > 

sh/dxnodes 

Accessing remote database on NOJO...standby... 

KAT7EHK de N7AVK 4-Apr 05432 > 

This database lists DX Nodes by STATE: SH/DXNODES VA 

and by AFFILIATION: SH/DXNODES PVDXSN 


For a list of Affiliations type SH/DXNODES AFF 


Please send changes/updates to your SYSOP for forwarding to NV6Z 


This Database is Distributed by W6GO/K6HHD. 


The preceding data base is the source for Appendix 11. 


KAT7EHK de N7AVK 4-Apr 05462 > 

show/band 

Accessing remote database on NOJO...standby... 
KAT7EHK de N7AVK 4-Apr 0548Z > 


TO FIND THE OPERATING PRIVILEGE FOR A CLASS OF LICENSE DO THE 
FOLLOWING: 


1. TYPE SH/BAND DIR THEN ENTER. 

2. LOCATE THE BAND AND LICENSE CLASS FOR INFORMATION YOU NEED 
3. FIND KEYCODE FOR BAND AND LICENSE CLASS IN ITEM 2 

4. TYPE SH/BAND KEYCODE (USE THE KEYCODE LISTED) THEN ENTER 


HOPE YOU DON'T GET A PINK SLIP NOW! 


Updates/corrections to KES5IV. 5/90 -— Distributed by W6GO/K6HHD 
KAT7EHK de N7AVK 4-Apr 05502 > 

show/coord 

Accessing remote database on NOJO...standby... 

KAT7EHK de N7AVK 4-Apr 05502 > 

The SHOW/COORDinates command provides the longitude and latitude of 
various cities in the United States and DX locations. You may use 
this information to set your location (SET/LOCATION). Enter SH/COORD 


[key] where key is a 2-letter state designator, example SH/COORD CA; 
or SH/COORD [pfx], example SH/COORD VK. A plus (+) indicates 
airport/VOR location. 


Your updates and comments are welcomed. Type SH/COORD AUTHOR for 
info. 
Database by: K6PBT Distributed by W6GO/K6HHD via DX-BBS and GODISK. 


KAT7EHK de N7AVK 4-Apr 05512 > 

sh/iota 

Accessing remote database on NOJO...standby... 
KA7EHK de N7AVK 4-Apr 05512 > 


SHow/IOTA (Islands on the Air) displays requested IOTA island data 
and name cross-reference information. For official IOTA status/info, 
one should consult a current IOTA Directory. SH/IOTA DIR or NOTES 
for more. 

* TOTA Ref Nbr SH/IOTA OC-7, NA-113, etc. (Continent plus —Ref#) 
* Tsland Names SH/IOTA EUA, ASB, SAC, etc. (Continent plus A - Z) 
Your updates and comments are welcomed. Type SHow/IOTA AUTHOR for 
info. 

Prepared by: K6PBT Distributed by W6GO/K6HHD via DX-BBS and GODISK. 


KA7EHK de N7AVK 4-Apr 05532 > 

show/pub 

Accessing remote database on NOJO...standby... 
KAT7EHK de N7AVK 4-Apr 05532 > 


The SHow/PUB command is used to display information on Amateur Radio 

publications from various countries. A simple process is provided 

for adding publications to this database. 

SYNTAX: SHow/PUB KEY How to search for pubs from a specific country 
SHow/PUB ADD How to add a publication to this database 


Your updates and comments are welcomed. Type SH/PUB AUTHOR for 
information. 


Database by N6IXX Distributed by W6GO/K6HHD 13-August-—90 
KAT7EHK de N7AVK 4-Apr 06002 > 

sh/gqslrec 

Accessing remote database on NOJO...standby... 

KAT7EHK de N7AVK 4-Apr 06002 > 


The SH/QSLREC command is used to display information on QSL cards 
received by users of this Cluster. You can easily update QSLREC with 
information on QSL cards you receive by using the UPDATE ( OR ) 
APPEND command (see below). 


SHow/QSLREC (Call) Check for QSLs received from a specific station 
UPDate/QSLREC Add NEW received QSL info to the QSLREC 
database 


UPDate/QSLREC/APPend Add MORE received QSL info to an EXISTING 
QSLREC entry 

Your updates / comments are welcomed. Type SH/QSLREC AUTHOR for 
information. 

Database by N6IXX Distributed by W6GO/K6HHD 1-September-90 


KAT7EHK de N7AVK 4-Apr 06012 > 


show/buckmaster 
Accessing remote database on WR7D...standby... 
KA7EHK de N7AVK 4-Apr 06012 > 


FCC records plus VE and some DX provided by ab9o0, updated Oct. 92 


This data base is discussed in some more detail in the next section. 


KAT7EHK de N7AVK 4-Apr 0519Z > 

show/mic 

Accessing remote database on NOJO...standby... 
KAT7EHK de N7AVK 4-Apr 05232 > 


MicPlug Database 
For Different TNC and for other uses 
Rev: Oct 11, 1990 


This database is to search different types of Radios to see 


how and where to connect your mic plug wires to. The database 
contains direct instructions on MFJ, DRSI, PK232, PK88 and other 
TNC's, but you can use the data for all TNC's as well. To see 

available radios in the database do a [SHOW/MIC INDEX]. For 


information concerning the programmer [SHOW/MIC AUTHOR] 


The preceding data base is used as part of the information for Appendix 
4. 


KAT7EHK de N7AVK 4-Apr 05252 > 

show/today 

Accessing remote database on NOJO...standby... 
KAT7EHK de N7AVK 4-Apr 05252 > 


SHow/TODAY was inspired by a PC program called TODAY by Patrick 
Kincaid. Enlighten your QSO's with a topic from a daily view of 
TODAYs databank of history events. For updates or comments, SH/TODAY 
AUTHOR. 


SH/TODAY [date] - where [date] is a 4-digit number, 01-12 for 
the month, and 01-31 for the day; ie. SH/TODAY 0521 would 
display events for May 21st. 


Included is a perpetual calendar covering the years 1970 to 2029. To 
find a day/date for a particular year/month, SH/TODAY CALENDAR. Try 
it! 

KA7EHK de N7AVK 4-Apr 05262 > 


7.J CALLBOOK SERVER 


Of the data base servers described in the previous section, the callbook 
server will be examined in a little more detail. This is primarily for 
comparison with the other callbook servers described in section 5.D. 


Note that this particular data base includes Canadian and some DX. The 
following example shows the response to a request for the author's call 
and for for VE7DIE. 


KAT7EHK de N7AVK 30-Mar 07352 > 
show/buckmaster KA7EHK 
Accessing remote database on WR7D...standby... 

KAT7EHK de N7AVK 30-Mar 07362 > 

HamCall (c) 1992, Buckmaster. Licensed for non-pecuniary use only. 
James D. Wagner, KA/7EHK License class: T Born: '41 

31677 N Lake Creek Dr 
Tangent, OR 97389 
KATEHK de N7AVK 30-Mar 07372 > 
show/buckmaster ve7die 
Accessing remote database on WR7D...standby... 

KAT7EHK de N7AVK 30-Mar 07372 > 

HamCall (c) 1992, Buckmaster. Licensed for non-pecuniary use only. 
Lawrence Micheal Joe, VE7DIE 
4174 Cross Haven Close 
Victoria Bc, V8X 4H3 Canada 
KAT7EHK de N7AVK 30-Mar 07382 > 


7.K OTHER DX SPOTTING NODES 


Recent versions of the MSYS BBS software includes a DX Server. 
Since MSYS is full-service store-and-forward BBS software, the mail 
service follows that of a normal BBS rather than the slightly different 
style described in this chapter. It is not likely that MSYS DX spotting 
would network easily with the Pavillion node software previously 
described. 


In its simplest form, any of the converse servers can be used for DX 
spotting. While such DX spotting would be without all of the bells and 
whistles relating to callsign filtering and the like, there is no reason why 
it could not work. The distributed converse server found in JNOS and 
other NOS versions could also implement a distributed DX spotting 
system. While the author has no first-hand knowledge of such systems, 
there is no (obvious) practical reason why they should not work in this 
application. 


7.L SUMMARY 


This chapter has discussed one specific implementation of a DX 
Spotting Node. There are several commands such as upload and 


download which have not been discussed. This is because both space 
is limited and it was not felt that these would be commonly used 
commands. 


If you encounter other styles of DX spotting nodes, just be aware that 
they are likely to be fairly similar to what has already been described. 
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The primary focus of this chapter is the basic concept of radio 
networking. The ideas are not difficult. Unfortunately, however, the 
language which is often used can be difficult to understand because of 
the intense academic study around networking. Those terms which 
really do apply to ham networks will be explained and so will the 
concepts. Chapters 9 & 10 describe several types of networks which 
are in wide use by hams. 


8.A WHAT IS A NETWORK? 


The "Webster's New Collegiate Dictionary" (1974) provides the 
following definition of a network: 


net-work n 1: a fabric or structure of cords or wires that cross at regular 
intervals and are knotted or secured at the crossings 2: a system of lines 
or channels resembling a network 3: an interconnected or interrelated 
chain, group, system <a network of hotels> 4a: a group of radio or 
television stations linked by wire or radio relay 4b: a radio or television 
company which produces programs for broadcast over such a network. 


In a very general sense, personal packet stations can thus be considered 
a network. This general sense of networking is inherent in the very 
construction of packet radio. At this level, nodes are not an issue. 
Software (such as LanLink) in personal stations can make this happen 
pretty easily at individual stations. These stations can also be used as 
digipeaters for wide-area service but such a network requires a very high 
knowledge of every detail. 


In the narrow sense, a network is a system of stations (called, in our 
case, nodes or packet switches) that are linked by radio or other 
methods. Nodes provide connection services. But if the node is isolated 
from other nodes, the connection service is local, only; if the node has 
no user access, the connection service 1s wide-area, only. 


8.B WHY HAVE NETWORKS? 


There are a number of reasons why networks are so attractive. 


8.B.1 WIDE-AREA CONNECTION SERVICES: Users (usually) do 
not need to know the details of network operation or structure to reach 
moderately distant network points. The degree to which network details 
are hidden depends on the network protocol being used. There are 
several protocols in general ham use (NET/ROM, TexNet, FlexNet, 
ROSE, TCP/IP) and each hides network details to varying degrees and in 
varying ways. 


8.B.2 ERROR CORRECTION: All of the protocols we use provide 
additional error correction beyond that of basic packet stations or 
digipeaters. 


8.B.3 FAULT TOLERANCE: When reasonably well designed, networks 
provide some degree of equipment failure tolerance. When one part of 
the network fails, the network provides alternate ways of providing its 
wide-area connection service. Usually, the wide-area connection service 
continues in the presence of the failure without any special action on the 
part of the user (unless the failure involves either the network destination 
or the one-and-only way to reach the destination). The degree to which 
intervention is required by node operators depends on the protocol. 


8.B.4 GOOD OPERATION: Lest this list of good reasons for having a 
packet network leave you with a "warm-fuzzy" feeling, be aware of this: 
the mere existence of a network does not guarantee good operation! 
There are quite a few technical reasons why a given network might not 
work well. See, particularly, section 8.D. 


8.C NETWORKING NODES & SWITCHES 


The terms node and switch are generally synonymous. But, generally, 
ROSE networks call their nodes packet switches and NET/ROM 
networks call their's nodes. Here, the term node will be used with the 
understanding that the term is intended to apply equally to those devices 
frequently called packet switch. 


A node manages networking details. What the details are and how they 


are managed depend greatly on the protocol in use. 


Nodes often, but not always, provide network access to users. 
Sometimes, nodes are set up only for the purpose of joining two sections 
of a network; if there is little or no reason for user access at that point, 
the node operator may economize and leave out the radio for user 
access. In some cases, such as TCP/IP and certain other personal-use 
mailboxes, personal stations may also be nodes. 


Nodes sometimes offer other services beyond the basic connection 
services. This often include bulletin boards, weather servers, etc. 


Occasionally, nodes are isolated (that is, not part of a network). This 
may be true because of geography or it may be true because the node 
operator does not want it to be part of a wide-area network. In either 
case, such nodes can only provide local services (mailbox, etc). 


8.D NETWORK ARCHITECTURE 


There is a variety of network architectures in use throughout the 
country. Lets look at several examples which are independent of the 
networking software. They apply equally well to Net/Rom, ROSE, 
TexNet, FlexNet, or TCP/IP. There are also a significant number of 
networks which contain "worm-holes". These are links which are not 
traditional ham-radio links. They may be commercial satellite links. 
They may be internet links (see Chapter 15). They may be leased or 
"borrowed" links on commercial common carries such as AT&T, or 
SPRINT using cable, microwave, or optical fiber. The presence of 
these links does not really alter the schemes shown below. Just imagine 
that one of the links shown as an RF link is some other medium which 
has the same end-end Physical Link characteristics (see section 11.C). 


8.D.1 SINGLE FREQUENCY NETWORK: One of the first networking 
schemes used the same frequency for users and node-to-node linking. 
This system is still widely used in parts of British Columbia, Alberta, 
Montana, Wyoming, Southeastern Idaho, parts of Utah, and Nevada (all 
on 145.01MHz). Northern California and Southern Oregon also have 
single frequency systems. 


FIGURE 3-1 
SINGLE FREQUENCY NETWORK 


These work fine so long as the user level is low. This kind of network 
can, however, become easily overloaded as one node's users are hidden 
to the next node. Similarly, with a network which covers a very wide 
area as these often do, many nodes are hidden to others in the same 
system. Under the right circumstances (not very many users), the 
system does work. 


8.D.2.WIDE AREA BACKBONE: The next evolutionary step and a 
substantial improvement over the single frequency network is the 
addition of a "backbone". Here, every node contains two transmitters 
operating on different frequencies. One is for users and one (same 
frequency for all nodes) is for node-to-node linking. This is shown in 
Figure 8-2. 


Since each user frequency of each node is different, one node's users 
are of no importance to the next node. Congestion drops significantly. 
Users see a great decrease in retry rate and the time required for packets 
to move between nodes drops significantly. 


The change to this network style usually occurs because of user 
pressure. And the change is usually accompanied by a rapid growth in 
new users (or "old" ones returning because it now works much better). 
In fact, there is acommon belief that the single frequency systems 
continue to operate only because its poor performance discourages 
growth in user numbers! In many metropolitan areas, the growth has 


been so great that even this style is no longer adequate. 


FIGURE $-2 
SINGLE BACK BONE NETWORK 


What's wrong with this network? The problem is that it covers a large 
area on a single backbone frequency. Some parts of the network are 
hidden to other parts. Studies by WORLI and others in the Portland, 
Oregon area have shown that the maximum number of nodes on a single 
frequency when BBS forwarding is involved should not exceed about 4! 


8.D.3 BACKBONE "CLUSTERS": The cluster system places a few 
neighboring nodes on a single backbone frequency (which is a different 
frequency than the one used for the same purpose by other near-by 
nodes). The nodes on a single frequency form a "cluster". Then, 
another frequency (often on a different band) is used to join clusters. 
Figure 8-3 illustrates this arrangement. 


In the Northwest, frequencies near 223 MHz (1.25 Meter band) are 
often used for cluster frequencies and frequencies in the 70cm band 
(near 430 MHz or 440 MHz) are often used for cluster-cluster linking. 
There is, however, no firm rule about frequencies used. In Southern 
California and Nevada, 50MHz band (6 Meter band) has been used. 
Frequencies above the 70cm band have also been used. 
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FIGURE 8-3 
CLUSTER NETWORK 


This arrangement requires at least some of the nodes in a cluster to 
contain 3 (or more) ports. Of course, this raises the cost of a node. 
And not all sites can provide antenna space or power for such 
installations. 


8.D.4 POINT-POINT LINKS: As clusters shrink in number of 
members, the extreme case is that each frequency has only 2 nodes. 
The links are then called "point-point" because they go from one single 
point to another. This style of network is shown in Figure 8-4. 


If the link is reasonably good, the retry rate drops to a very low value 
because there is no competition for the frequency. Directional antennas 
can now be used between nodes and this improves both the received and 
transmitted signal from both partners. Every packet which enters a node 
leaves on a different frequency. Of course, the cost goes up. 
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FIGURE 3-4 
POINT-POINT LINK NETWORK 


8.E WHAT'S IN A NODE? 


Nodes are the work-horses of packet networks. It may be intuitively 
obvious that a node needs a radio for each frequency that it operates on. 
It may also then seem reasonable that an antenna is also needed (usually) 
for each frequency. But is is less obvious what else is required to make 
a node work. 


8.E.1 Single-frequency TNC nodes: The simplest node is probably 
the single-frequency node built from a TNC. The usually preferred 
TNC type is the TNC2-clone. This is because the special ROM which 
makes the TNC operate as a node is designed only to operate in this kind 
of TNC. This type of node may also be called single-port. 


8.E.2 Multi-frequency TNC nodes: This node arrangement consists 
of several single-frequency nodes joined together. 


The basic arrangement is shown in Figure 8-5. It is frequently called a 
node-stack. This name is derived from the common arrangement for the 
TNCs and radios... that is, they are frequently placed on top of each 
other in a "stack". It is also referred to as a multi-port node. 


to anteriris. 


diode matrix 


FIGURE &3 
MULTI-NODE STACK 


The connection between them is through the connector where a terminal 
normally is attached to the TNC. The common connection point is in a 
device called a diode matrix. This device keeps TNCs from attempting 
to all send signals to other TNCs at the same time. 


The program ROMs in the TNCs are the same as in the single-frequency 
version. 


8.E.3 Multi-frequency Computer-based nodes: This node 
arrangement relies on a computer to carry out the packet management 
and network operation. TNCs are still used but they function much 
more like a conventional modem. Figure 8-6 shows how such a node is 
constructed. 


bo antennas 
radios 


seta) cables 


FIGURE §-6 
TYPCIAL MULTI-PORT STACK 


This node setup is most commonly found with bulletin boards. The 
TNCs, themselves, operate in a mode called KISS (which stands for 
Keep It Super Simple); this mode is available in most TNCs and causes 
them to operate very nearly as a conventional modem. 


8.E.4 Multi-frequency DataEngine nodes: This node uses a new 
device called DataEngine (manufactured by Kantronics). The device 
comes with two modems and is capable of operating to 9600 baud. 
Thus, by connecting two radios (of the appropriate kind) to it, a 
two-port node can be very easily constructed. A conventional TNC may 
be attached to the computer port to make a 3-frequency node and two 
DataEngines may be connected together to make a 4-frequency node. 


8.E.5 TexNet nodes: These nodes are (minimum) two-port devices 
readily supporting both 1200 baud and 9600 baud. The low baud-rate 
port operates using standard AX.25 and the other ports use a protocol 
known as TEXNET-IP. Thus, on the backbone side, they are not 
compatible with the nodes previously discussed. 


8.E.6 FlexNet nodes: FlexNet nodes are not based on TNC2s. They 
are referred to as RNMCs (Rein Main Network Controllers). These 
nodes are becoming widely used in Germany, Belgium, France, 
Switzerland, Austria, Italy, and Hungary. This spread is thought to be 
(at least partly) due to the low cost of the nodes. 


RNMCs can support up to 6 ports. A 1200 baud user port is common. 
Like TexNet, node-to-node linking does not use Net/Rom protocol. 
Interestingly, this protocol is designed carry almost any other protocol 
wrapped inside its own. Node-node links are commonly operated at 
9600 baud. 


8.F SUMMARY 


In this chapter, we have attempted to look at networks in a rather broad 
sense. We found that networks can provide wide-area connection 
services, additional error correction, network-level fault tolerance; but 
we also found that just because a network exists, there is no guarantee 
that it will work well! 


Networking nodes manage the details of the network. Nodes can also 
provide access to the network for users and may also provide other 
services such as bulletin boards. 


Networks may be arranged in a number of ways. The most rudimentary 
is the single-frequency system where nodes link with each other on the 
same frequency that users occupy. The next level of improvement is the 
single-frequency backbone system. Here, nodes are joined on a 
common frequency called a backbone while each has a different user 
frequency; the ability to support large numbers of users is quite a bit 
better for this system than for single-frequency systems. Cluster 
systems divide the network into smaller backbones which are joined by 
links on different frequencies. Point-point link systems use a unique 
frequency between each node and has the best ability to support many 
users of all of the network styles discussed. 


Nodes, the key elements of networks, come in several basic varieties. 
The simplest is probably the single-frequency node built from a TNC 
with a special program ROM. Multi-frequency nodes may be 
constructed several ways. One way is to connect together a number of 
TNC-based nodes (one TNC per frequency). Another is to use a 
multiport controller such as a Data Engine. Yet another is to use a 
computer as the core of one or more nodes. Finally, special nodes may 
be constructed (as in the case of TexNet). 


The network characteristics discussed in this chapter are independent of 
the protocol used. For more information about NET/ROM networks, 
see Chapter 9. For more information about TexNet, ROSE, TCP/IP and 
FlexNet networks, see Chapter 10. For the most detailed information 
about every node type available to the author, see Chapter 24 in Volume 
on 
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This chapter and the next discuss the packet servers called nodes in 
more detail than the introduction of Chapter 5. The focus here is the 
group of node types which are based on the Net/Rom networking 
protocol. Chapter 10 focus on several other protocols (KaNode, 
TexNet, FlexNet, ROSE & TCP/IP). The goal of this chapter is to 
provide enough information so that you can use the Net/Rom packet 
network effectively. It also will attempt to convey some of the delights 
and frustrations of using this network. 


There is quite a variety of node types which fall in the Net/Rom 
category. Here, the discussion tries to cover general principles of how 
they provide connection service. Chapter 25 in Volume 2 provides 
reference information about specific node implementations. 


9.A WHAT IS NET/ROM NETWORKING? 


The term Net/Rom is derived from the protocol developed by Software 
2000 (apparently no longer in business). This protocol enabled TNCs 
with a different program memory (ROM) to automatically construct 
networks, route user connections between TNCs called nodes, and 
provide connection services. 


Now, there are many node software implementations which use this 
protocol. They include TheNet, G3BPQ, MSYS, & NET/NOS 
(including JNOS). Networks built around this protocol cover most of 
the United States and Canada and are in use in many other parts of the 
world. 


So, what is NET/ROM networking? 


9.B NET/ROM NODES 
Net/Rom nodes do the following things which define this protocol: 


9.B.1 Neighbor list: the node maintains a list of directly heard 
neighbors. Neighbors are recognized by the specific pattern of their 
beacon. The node stores the neighbor's node name, callsign, the port 
on which it was heard, and number of possible routes to the neighbor. If 
a neighbor has not been heard in a specific time interval (called 
obsolescence time), the entry is removed from the neighbor list. Note 
that this list is adaptive and changes with changes in the surrounding 
network. While this results in a network requiring little manual support 
by the node operator (or anyone else), there are some specific problems 
which this process produces. 


9.B.2 Destination list: the node maintains a list of possible destinations 
(called the node list). This list includes all neighbors plus all of the 
destinations which are reported by neighbors and which have an 
adequately high route quality. The route quality for inclusion in the node 
list is set by each node operator. 


9.B.3 Destination list beacon: nodes beacon the entries in their node 
lists. This beacon is heard by neighbors and is used to construct 
destination lists. This shared information is used to construct routes 
automatically (autorouting). 


9.B.4 Construct autorouted circuits: when a connect request to a 
distant node is received by a Net/Rom node, it begins the process of 
constructing a circuit to the distant node. The construction of the 
circuit is based on route quality which is discussed in more detail later in 
this chapter. Once a circuit is constructed, it becomes a pipeline for 
packets between the node which started the circuit and the destination 
node. 


9.B.5 Local connection service: when a user is connected to a 
Net/Rom node, a connection to a local station may be requested. The 
node will attempt to make the connection, using the user's callsign but 
with the user's SSID changed to 15-(userSSID). 


9.B.6 Other services: the node may provide other services. 
Standard services include node list, route list, and user list. In addition, 
bulletin board service, callbook service, etc. may be supplied (see 


Chapter 5). 


9.C BASIC NODE LIST 


Node lists are discussed in detail in several other sections of this chapter. 
However, in order to interpret what is happening with route quality, we 
need a little bit of information about how node lists work in 
Net/Rom-style nodes. 


The following TheNet example was chosen specifically because its node 
lists are small. Sending N/ode] causes the node to return a list of 
known destinations. This list may not be complete, however, because 
most nodes just return the names of node user-ports. For nodes in 
which this is true, sending N/ode] * causes the node to return a list of 
all known destinations, including backbone-port names (which begin 
with #). 


n 
VALLEY :N7FGF-3} Nodes: 


CRS: NV7N-14 EM4 : WB6LMA-4 KENO:NV7N-2 KLMT : NV7N-1 

LKV: KJ6ZP-1 MFR:WA7FAB-4 OAK : W7EXH-1 RDG: WA6YNG-1 
n* 

VALLEY :N7FGF-3} Nodes: 

#EUG:W7EXH-12 #EUG4 :W7EXH-8 #EUG5 :W7EXH-9 CRS: NV7N-14 

EM4 : WB6LMA-4 KENO:NV7N-2 KLMT : NV7N-1 LKV: KJ6ZP-1 

MFR:WA7FAB-4 OAK : W7EXH-1 RDG: WA6YNG-1 


9.D ROUTE QUALITY 


Route quality is crucial to the routing process in a Net/Rom network. It 
is also one of the most confusing pieces of information available from a 
Net/Rom-style node. 


9.D.1 NEIGHBOR ROUTE QUALITY: At each node, every directly 
heard neighbor is given a route quality which ranges from O to 255 
(bigger is better). It is important to recognize that the assigned route 
quality may not have any relationship to the actual quality of that route 
at any given moment. Route quality values are assigned by the operator 
of the node. The node operator may choose to give all stations heard on 
a particular port a blanket quality value. The node operator may choose 
to manually assign a unique quality to each and every neighbor. Or the 
node operator may choose to manually assign unique route qualities to a 


few and a blanket value to all of the remaining. Each of these schemes 
is in use in various areas and it is often an issue which brings on intense 
debate. 


The important fact to note, however, is that the operator chooses the 
route quality. It is not determined by how easy it is to get packets to or 
from that neighbor. Thus, if antenna damage, propagation changes, or 
anything else alters how good a particular route is, unless the node 
operator changes it, the same value still applies. 


Lets look at a Net/Rom style node and see how neighbor route qualities 
are reported: 


SALEM:AF7S-—-1} Routes: 
> K7UYX-1 224 8 

> N7IFJ-9 224 2 
N7HZT-9 192 2 
KAT7AGH-8 224 151 
N7TLD-8 224 4 
K7MYU-9 192 2 
KAT7UPD-1 224 57 
W7VTW-11 224 44 


> 


> 
> 


WNHRNNEF DN W 


For the record, this is from a G8BPQ node which uses Net/Rom 
protocol. This is a 3-port node and the numbers preceding the callsigns 
indicate the port on which each of these neighbors was heard. All 
neighbors on port 3 of this node share a 1.25 meter cluster and have 
been given route qualities of 224. All neighbors of this node on port 2 
share a 70cm, 9600 baud frequency and have been given route qualities 
of 224. All neighbors on port | are on the 2 meter user frequency and 
have been given route qualities of 192. The remaining numbers and 
symbols will be discussed later in this chapter. 


Lets look at another node which shows some of the other route quality 
issues. This one is a TheNet backbone port of a two-TNC node stack 
of the type discussed in section 8.E.2. 


#ALW:WA7HJIV-10} Routes: 
> 1 ALW:WA7HIJV-5 255 1 
#BOIS3:N7FYZ-6 0 0 ! 
WB7DOW-13 0 0 ! 
#YKMSL:KB7HDX-7 0 O ! 
W7SC-1 0 0 ! 
#HOME:KB7CFD-3 0 0 ! 
KB7DBD-8 0 0 ! 
K7YLO-2 0 0 ! 
#ONO2:WB7RES-6 0 0 ! 


OOOO COOCO 


#NUKE:K70J—-7 224 51 
#PDT:N7ERT-10 224 71 
#BKE:W7NYW-9 224 17 
#IDY:N7LZM-7 224 17 
#SPOKN:WB7NNF-7 224 44 


VV 
oOOOCO 


With TheNet nodes, there are two places where a neighbor may be 
heard. Neighbors heard over the radio are port-O0 neighbors and a zero 
precedes their callsign. Neighbors which are other members of the same 
node stack are port-1 neighbors and a | precedes their callsigns. 
Normally, other members of the same node stack are given quite high 
route qualities; here ALW:WA7HSJV-5 is given a quality of 255. Some 
radio neighbors are given a quality of 224. Some others are given 
qualities of 0. This is done in this case because they may be heard only 
once in a while or, even though heard, may not have an adequate path 
for normal communication. 


9.D.2 DESTINATION ROUTE QUALITY: It is sometimes hard to 
imagine how destination route quality comes about. The difficulty often 
arises because of confusion about what comes first. In fact, networks 
evolve and the route quality entries are a product of that evolution. 


To see how this evolution occurs and what its result is, lets consider a 
very simple case. This simple case involves an isolated node named 
BIGTWN. Then, nearby (but not too nearby), a node named PODUNK 
is built to link with BIGTWN. Finally, to improve things, HILTOP is 
added. Lets see what happens during this progression. 


STEP 1 - BIGTWN on line: We will pretend that there is a single, 
isolated, node named BIGTWN:NAIBC-1 (ie, Bigtown). It plaintively 
beacons UI packets (see section 4.D.1) from NA1BC-1 addressed to 
NODES. The beacon says that it is a routing broadcast (with a special 
character first in the message), then says "my node name is BIGTWN". 
It says no more because it does not know anything about any other 
nodes. 


STEP 2 - PODUNK on line & beacons: Now, suppose that a group of 
hams at Podunk decide that they want to talk to their packet friends in 
Bigtown. So, they put up a node named PODUNK:KB2XYZ-1. Soon 
after being turned on, PODUNK sends a beacon very much like the ones 
BIGTWN has been sending. This is because, at this point, it has not yet 
heard from any other nodes. BIGTWN hears this beacon, and if we 
were to ask for a node list from it, would get: 


n 
BIGTWN:AB7BC-1} Nodes: 
PODUNK: KB2XYZ-1 


And if the BIGTWN node operator had set the neighbor route quality to 
192 (not uncommon for this kind of network), the route list from 
BIGTWN would read: 


R 
BIGTWN:AB1BC-1} Routes: 
0 PODUNK:KB2XYZ-1 192 1 


PODUNK was heard on BIGTWN's the radio port, has a quality of 192, 
and knows the route to 1 destination (itself). The next beacon from 
BIGTWN now changes because, for the first time, it has an entry in its 
destination list! 


STEP 3 - BIGTWN beacons: BIGTWN beacons again with a UI packet 
from NAIBC-1 addressed to NODES. The beacon says that it is a 
routing broadcast (with a special character first in the message), then 
says "my node name is BIGTWN". But this time, it also says "I have a 
route to KB2XYZ-1 which is named PODUNK. The neighbor of mine 
which which has the best quality route to KB2XYZ-1 is KB2XYZ-1 and 
the route quality by way of that neighbor is 192". The latter may be a bit 
confusing and a bit redundant. This is, however, the standard set of 
information. 


PODUNK, in turn, hears BIGTWN's beacon. From that beacon, it 
determines that BIGTWN knows about 2 destinations (BIGTWN, itself, 
and PODUNK). PODUNK considers the latter a trivial route because it 
is a route to itself, but counts it, none the less. A user at PODUNK 
would then see: 


n 
PODUNK: KB2XYZ-1} Nodes: 
BIGTWN:AB7BC-1 
R 
PODUNK: KB2XYZ-1} Routes: 
0 BIGTWN:AB7BC-1 192 2 


After the next beacon from PODUNK, BIGTWN recognizes that 
PODUNK also has two routes. BIGTWN's route list changes 
accordingly. 


STEP 4 - HILTOP on line & beacons: Now, after a little use (probably 
not very much) the users of both BIGTWN and PODUNK discover that 
the route is not very good. Retry rate is pretty high (which all can see 
by monitoring). Somebody then notices, a little belatedly, that Big Rock 
Hill just happens to be directly in the path between the two. After much 
head scratching and discussion about whether or not it is all worth it 
(and, of course, it is), the two groups decide to get together and install a 
node part way between BIGTWN and PODUNK. This new node is 
HILTOP:W3AZ-1 (Hilltop) After a reasonable amount of preparation and 
testing, it is installed and the new network looks something like what is 
shown in Figure 9-1. 


Big Rock Hill 


HILTOP 
Podunk 


Bigtown 


Figure 10-1 
BIGTWN-HILTOP-PODUNK NETWORK 


The lines in Figure 9-1 attempt to show the poor path directly from 
PODUNK to BIGTWN and the (expected) good paths from HILTOP to 
PODUNK and to BIGTWN. What happens when HILTOP goes on the 
air and beacons for the first time? 


Assuming that HILTOP beacons before it hears either of the other two 
nodes, it is much like when PODUNK went on the air. The first beacon 
just says that HILTOP is on the air. The beacon is from W3AZ-1 and is 
addressed to NODES; it says that its name is HILTOP. There is nothing 
more because it knows nothing of the other two nodes (yet). 


Suppose that users were to connect to each of these three nodes very 
shortly after HILTOP's first beacon. Each would see the following: 


n 
BIGTWN:AB7BC-1} Nodes: 
HILTOP : W3AZ-1 PODUNK: KB2XYZ-1 
R 
BIGTWN:AB1BC-1} Routes: 
0 PODUNK:KB2XYZ-1 192 1 
O HILTOP:W3AZ-1 192-4. 


n 
PODUNK: KB2XYZ-1} Nodes: 
BIGTWN:AB1BC-1 HILTOP :W3AZ-1 
R 
PODUNK: KB2XYZ-1} Routes: 
0 BIGTWN:AB1BC-1 192 1 
O HILTOP:W3AZ-1 192 1 


n 
HILTOP:W3AZ-1} Nodes: 
R 
HILTOP:W3AZ-1} Routes: 


Note that HILTOP does not yet know anything about the other two 
nodes. PODUNK has now heard BIGTWN & HILTOP. BIGTWN has 
now heard PODUNK & HILTOP. But that is only part of the story. 


STEP 5 - PODUNK beacons: If PODUNK happens to beacon next, it 
now has something to say. Again, the beacon is from KB2XYZ-1 and is 
addressed to NODES. It says that its name is PODUNK. Since it has 
heard from both BIGTWN and HILTOP, it says (in effect) "I know the 
way to BIGTWN which has the call AB1BC-1; the neighbor with the 
best route to itis AB1BC-1 and that route has a quality of 196. I know 
the way to HILTOP which has the call W3AZ-1; the neighbor with the 
best route to it is W3AZ-1 and that route has a quality of 196." 


When BIGTWN hears this beacon, things change quite dramatically even 
though one will not see the effect in the node or route list. Now, 
BIGTWN has heard HILTOP directly and it has heard that PODUNK 
knows the way to HILTOP. PODUNK said that its route quality to 
HILTOP is 192. BIGTWN discounts this route quality according to the 
quality of the link between itself and PODUNK. Since it gives all 
neighbors a quality of 192 and 256 is perfect, it determines that the route 
to HILTOP through PODUNK has a quality of 192 * (192/256) = 144; 
the first 192 is the quality reported by PODUNK's beacon and the 
192/256 is the reduction due to the quality of the BIGTWN-PODUNK 
link. If a BIGTWN user were now to request information about routes 
to HILTOP, BIGTWN would return: 


N IHLTOP 

BIGTWN:AB1BC-1} Routes to HILTOP:W3AZ-1 
192 5 0 HILTOP 
144 6 0 PODUNK 


Note that it shows a route quality of 192 in the direct link to HILTOP 
and a route quality of 144 by way of PODUNK. The significance of this 
difference should become obvious during the discussion of autorouting. 


STEP 6 - BIGTWN beacons: If BIGTWN beacons next, it again says 
that it is AB1BC-1 and is named BIGTWN. It says that it has a 
destination W3AZ-1 which is named HILTOP, the neighbor which has 
the best quality route to it is (also) W3AZ-1 and the route qaulity via that 
neighbor is 192 (only the one highest quality route is reported). It also 
says that it has a destination KB2X YZ-1 which is named PODUNK, the 
neighbor which has the best quality route is KB2XYZ-1 and the route 
quality via that neighbor is 192. 


STEP 7 - HILTOP beacons again: When HILTOP beacons a second 
time, it has heard the beacons from both PODUNK and BIGTWN. Its 
node list and route list are then filled: 


n 
HILTOP:W3AZ-1} Nodes: 
BIGTWN:AB1BC-1 PODUNK: KB2XYZ-1 
R 
HILTOP:W3AZ-1} Routes: 
0 BIGTWN:AB1BC-1 192 2 
0 PODUNK:KB2XYZ-1 192 2 


The beacon is now very much like the other two beacons. 


STEP 8 - FARWAY comes on line and beacons: To add a little realism 
to our little fable, lets now suppose that a node named FARWAY:A8ZZ-5 
comes on line. It is so far away that only HILTOP can hear it. When it 
beacons the first time, it, like the others, simply announces it presence. 
HILTOP hears it and HILTOP's node and route list become: 


n 

HILTOP:W3AZ-1} Nodes: 
BIGTWN:AB1BC-1 FARWAY :A82ZZ—-5 PODUNK: KB2XYZ-1 
R 
HILTOP:W3AZ-1} Routes: 

0 BIGTWN:AB1BC-1 192 2 

0 PODUNK:KB2XYZ-1 192 2 

0 FARWAY:A8ZZ-5 192 1 


But, up to the time when HILTOP beacons next, neither BIGTWN or 
PODUNK know anything of FARWAYs presence. During this interval, 
HILTOP is the only node which knows about FARWAY. 


STEP 9 - HILTOP beacons: The next beacon from HILTOP begins like 
all of the others. But there is now a new destination which it reports as 
A8ZZ-5 (called FARWAY) and the best route to it is the neighbor 
A8ZZ-1 by which the route is 192. When this beacon is heard by 
BIGTWN and PODUNK, their node lists change but the neighbor (route) 
list does not. For example, BIGTWN would show: 


n 
BIGTWN:AB7BC-1} Nodes: 
HILTOP : W3AZ-1 FARWAY :W822Z-5 PODUNK: KB2XYZ-1 
R 
BIGTWN:AB1BC-1} Routes: 
0 PODUNK:KB2XYZ-1 192 1 
O HILTOP:W3AZ-1 192 1 


Notice that, for the first time, there is an entry in the node list which is 
not also present in the route list. Suppose that, like one of the earlier 
steps, a user were to ask the route to FARWAY: 


R FARWAY 
BIGTWN:AB1BC-1} Routes to FARWAY:W8Z2Z-5 
144 5 0 HILLTOP 


BIGTWN reports a route quality of 144 because it heard that HILTOP 
had a route quality of 192. BIGTWN reduced the route quality to that 
distant node then by 192/256 for the same reason as in step 5. And if 
asked, PODUNK would show the same route quality and neighbor which 
knows the way. 


STEP 10 - BIGTWN and PODUNK beacon: The last step we will 
observe in this evolutionary odyssey is after both BIGTWN and 
PODUNK have beaconed. Their beacons both include this information: 
there is a destination W8ZZ-5 named FARWAY;; the neighbor with the 
best route is W3AZ-1 and the route quality via that neighbor is 144. 
After this pair of beacons, none of the node lists change but request for 
the route to FARWAY from BIGTWN now shows: 


R FARWAY 

BIGTWN:AB1BC-1} Routes to FARWAY:W82Z2Z-5 
144 5 0 HILTOP 
108 3 0 PODUNK 


Note that BIGTWN now thinks there are two routes to FARWAY. One 
is via the neighbor HILTOP. The other, and lower quality one, is via 
PODUNK (from which the route would next to to HILTOP, also). This 
latter route has been further devalued to 108 because PODUNK reported 
that the route quality there was 144. BIGTWN then reduced that by 
192/256 because of the 192 route quality between PODUNK and 
BIGTWN. 


We might continue to track how routes and their qualities evolve as more 
are added to the network and as the architecture of the network evolves 
from this single-frequency system into a backbone system. This is 
enough, however, because all of the principles have been discussed. 


9.E. AUTOROUTING 


Suppose that a user (at BIGTWN) in our preceding fantasy were to ask 
to be connected to PODUNK. The routing server in the node is 
activated. It asks "which neighbor has the highest quality to 
PODUNK?". To find the answer, it scans its destination table and finds 
that there are two routes to PODUNK. The highest quality is directly to 
PODUNK with a quality of 192. The next best one is via HILTOP with 
a quality of 144. 


The router tries to make the direct connection first. Lets suppose that it 
is not successful, since Big Rock Hill is in the way. There are so many 
retries that it fails before making the connection. Then, it tries the next 
best route, via HILTOP. Because the route is much better, the link to 
HILTOP is made very readily. Then HILTOP attempts to continue the 
route to PODUNK;; the route to that destination is PODUNK, itself. The 
link is good, and the connection is readily made. As soon as all of this is 
complete, the originating node then notifies the user of the successful 
connection. 


If the direct route from BIGTWN to PODUNK had not been so bad, 
BIGTWN might have been successful with the direct request. But what 
happens if conditions worsen and the link is no longer good enough to 
sustain operation? The Net/Rom protocol is designed to seek out an 
alternate route. In this case, it would attempt to remake the connection 
via HILTOP. Observation of this process, however, suggests that it 
does not work very well! 


9.F. MANAGED ROUTE QUALITY 


In section 9.E, we saw the consequences of route quality which does 
not reflect the real-world quality of routes. Some node operators take 
the view (with some justification) that a moderate degree of route quality 
management can improve the operation of some networks. 


In the preceding example, proponents of managed route quality would 
have manually set the quality of the link from (from either PODUN or 
BIGTWN) to HILTOP to 192 while setting the quality of the direct path 
between them to, say, 120. When BIGTWN is asked the route to 
PODUNK (which is the same thing the router would do), it would 
return: 


R  PODUNK 

BIGTWN:AB1BC-1} Routes to PODUNK:KB2XYZ-1 
144.50 HILLTOP 
T2030 -PODUNK; ! 


Note that the exclamation mark indicates that the PODUNK route has 
been manually set while routes involving HILTOP take on the route 
quality designated for all other routes. 


With this change, the route to PODUNK via HILTOP would have the 
highest quality and the router would always try it the first time. The 
poor quality direct route would only be attempted if the first one were to 
fail. If HILTOP were to go off the air, there would still be the direct 
path. There being no alternate routes, it would always be attempted as it 
was before HILTOP came into service. 


This is a fairly modest level of management. Some would argue, 
however, that Net/Rom works best when it is allowed to function 
without human tinkering. This debate, and its variations, has no real 
answer and you may see versions of it arise in various situations. 


9.G. THE LOST NODE PROBLEM 


Suppose that one of the nodes in the previous example suddenly 
disappeared. Perhaps power failed; maybe it was a transmitter or TNC. 


What happens to the autorouting? 


There is a timeout on all the route table entries (called obsolescence 
counter). If no word is heard from a node in a specific time, it is 
removed. The problem arises before that time has run out on all the 
nodes. Prior to that time, a node may broadcast its node list. That list 
will contain the entry for the lost node because its time has not run out. 
That broadcast will reset the timers in other nodes which hear that 
broadcast, at least as far a routing THROUGH those nodes is concerned. 
Thus, it may take quite a while for a node entry to finally disappear. 


The interim time is handled by a network parameter known as 
time-to-live. When a connect request is send out by a node, the 
time-to-live counter (contained in the packet header) is set to a 
predetermined value. Each time the packet passes through a node, the 
counter is reduced by 1. When the counter reaches 0, the node where it 
is simply discards it! This keeps packets from forever circulating 
through a network, looking for a node which cannot be reached. 


To see how this works, suppose that HILTOP were to experience a 
power failure. Then, further suppose that shortly after this power 
failure, a user at BIGTWN requests a connection to FARWAY. This 
node is still in the destination lists of both BIGTWN and PODUNK. 
BIGTWN attempt to make the connection via HILTOP, without success. 
It finds from its destination list that the next best route is via PODUNK. 
So, with some difficulty, it connects to PODUNK. The PODUNK 
destination list shows that the best route to FARWAY is via HILTOP and 
it, also, tries in vain. At PODUNK, the next best route is via BIGTWN! 
Connections keep getting made back and forth until the time-to-live 
count in the connect request reaches zero and is discarded. 


Suppose, now, that PODUNK makes a route beacon before the 
obsolescence counter of HILTOP times out. It broadcasts the fact that 
it has a route to HILTOP and FARWAY. At BIGTWN, the neighbor 
entry of HILTOP will time out but the beacon from PODUNK is newer 
and that one still says that there is a way to FARWAY. Thus, this entry 
may persist longer than HILTOP's! 


9.H. WHY AUTOROUTING DOESN'T ALWAYS WORK 


The previous section suggested several reasons why a connect request 


to a distant node might not work. There is, however, another reason 
and it is quite subtle. 


Suppose that you request a connection to a node which is more distant 
than the time-to-live number of your node? Perhaps you are in 
Ellensburg, WA and want a connect to SNOW (Salt Lake City, UT). 
There are about 9 intermediate nodes between the two. If time-to-live is 
set at 6, the connect request will get lost and never acknowledged! It 
may take a long time, if there are alternate routes (as there are in this 
example), for the failure message to appear. There are definite strategies 
to deal with this situation and they are discussed in the section 9.K. 


9.1. NODE NAMES 


A word may be in order concerning node names. In the U.S. West, the 
historical practice was to use airport/weather bureau designations. 
Thus, there were node names like SEA (Seattle), PDX (Portland), BOI 
(Boise) & SFO (San Francisco). That practice still continues. A 
problem arose as the number of nodes grew: there weren't enough of 
these names. Thus, we have names associated with geographical 
features (HEBO = Mt. Hebo, near Tillamook, OR and KING = King Mtn, 
near Wolf Creek, OR), names associated with callsigns (RLIMB = 
WORLI's MailBox) and full town names (BOISE). In Alberta, A 
common practice is to use the prefix AB on node names (as in ABHAT, 
Medicine Hat, Alberta). 


Another group of node names are associated with TCP/IP nodes (see 
Chapter 10 for more information). In much of the Western U.S., a 
common practice is to use a name which is the hex version of the last 
three sections of the stations IP address. Thus, for the node 74002C, 
the last part of its IP address is .116.0.44. In British Columbia & Alberta 
(and many other parts of the U.S.), the TCP/IP practice seems to be to 
use names like IPxxx or xxxIP. 


9.J. ROUTE LISTS: 


The route quality aspect of route lists has already been discussed in 
detail. Lets look now at some of the other information contained in a 
Net/Rom route list. 


Route lists gives a list of a node's immediate neighbors. In this case, 
immediate neighbor means a node which it has heard first hand without 
intervention by any other station. An example for a G8BPQ node looks 
like this: 


SALEM:AF7S—-1} Routes: 
> KAT7VAGH-8 224 109 
> N7DXT-10 224 30 
W7XI-13 224 26 
W7BH-11 224 12 
W7VTW-11 224 21 
KA7UPD-1 224 26 
N7KOJ-1 224 11 
K7UYX-1 224 30 
KA7KAJ-11 224 18 
N7IFJ-9 224 2 


NWWNDN WW WWW Dd 


> 


The style for this list varies a fair amount with node types. See Chapter 
25 of Volume 2 for details. But in this case, the neighbors are listed by 
callsign (some show only name, others show name and callsign). The 
number following the call is the route quality number. The last number 
is essentially the number of destinations in that neighbors destination list 
(all entries in the neighbor's node list, plus itself). 


There is a > symbol in the first column for some neighbors. This 
indicates that the link to that node is in use or has been in use very 
recently. 


The first number column has two meanings, depending on node type. If 
that column contains only O's and I's, a 1 means that the node is 
connected to the one you are on with a wire; a O indicates that it was 
heard over a radio. If, as in this case, there are numbers like 1,2,3, the 
numbers refer to port numbers and the number tells on which port the 
node was heard. 


MSYS nodes give a route list which looks like the following. It provides 
headings for each column and indicates the time in hours and minutes 
since a route beacon was last heard from each neighbor. There is no 
link activity indicator. 


cr 
#SRA:N7IFJ-9} Routes: 
Port Neighbor Node Call Quality Dests Heard 
Digipeater(s) 
0 SALEM: AF7S-1 192 136 02:42 
0) WASHCO:N7TLD-8 192 130 03:26 
Node cmd? 


JNOS nodes have a route list which is like this. The style is much like 
MSYS with some changes, of course. There are link activity indicators. 
JNOS uses named ports rather than numbered ones. There are two 
additional pieces of information. One is whether or not the neighbor is 
implements G8BPQ additions to the Net/Rom protocol as shown by the 
(BPQ) symbol. It also shows an obsolescence count. This count is 
commonly set to 6 each time a routing beacon is heard and is 
periodically reduced; the smaller this value is, the older the information. 


nr 
Routes 
Neighbour Port Qual Obs Dest 
JNOS40:WG7J-11 (BPQ) 2m 192 5 1 
> CRV:K7UYX-1 (BPQ) 2m 128 5 108 
CRVBBS :WG7J-1 2m 192 5 1 
1A0008:KB7IRS 2m LOR = 1 


Area: ka7ehk > 


9.K. WORKING OVER DISTANCES 


If you can't readily connect to a node a long ways away, how can you 
carry on conversations over a real distance? It isn't easy, but it can 
work. You need persistence and a little knowledge about the network 
(which hopefully was provided in the earlier sections of this chapter). 


You do need to be prepared for the following difficulties: unexpected 
disconnects, slow turn-around, networks which change, and 
unpredictability. Now that's an amateur radio challenge if ever there was 
one! 


How do you do it? The first secret is to connect to nodes at intervals of 
2-4 hops. This gets past the time-to-live dilemma described in the 
section 9.H. 


The second secret is go get, or make your own, map of the part of the 
network you are interested in. Earlier parts of this chapter have 
described how you can determine which nodes are neighbors to which. 
Most nodes respond to an J command; this returns node information. 
Nodeops have been much better in the last few years about putting 
useful information here. In particular, you need to look for location 
information if you don't already know. You may have to rely on 
deduction and guesswork based on the node name if you don't get clear 


help. 


The third hint is to do your longer distance work when the network is 
being lightly used. Late at night seems to be a good choice. So do early 
Saturday and Sunday mornings. Best seems to be after midnight, 
Sunday night. 


One hint which reduces the activity on your behalf in nodes is this: 
when you encounter NetRom style nodes with names beginning with #, 
they are usually backbone ports. If you are using that node as an 
intermediate point just passing through, connect to it instead of the user 
port. There is a possible trap in this strategy. One of the versions of 
TheNet permits the nodeop to disallow connect requests FROM the 
backbone port of the node to another backbone port. Fortunately, this 
option is rarely chosen. Unfortunately, the node does not tell you that it 
is refusing the request! 


The author and others in western Oregon have been able to carry on 
conversations with packeteers throughout the Northwest using these 
techniques. Join us! 
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This chapter focuses on several network schemes which do not follow 
the Net/Rom rules (KaNode, TexNet, FlexNet, TCP/IP and ROSE) . 
Chapter 9 was devoted entirely to Net/Rom networking. The goal of this 
chapter is to provide enough information so that you can use these 
packet networks effectively. 


10.A KANODES 


The term KaNode is apparently derived from the manufacturer's name, 
Kantronics. The products first developed by Kantronics made available 
in a well packaged product a device which provides basic connection 
services. While many are used only on VHF, their real popularity has 
been as two port nodes on VHF and HF. These provide an access 
method to HF for folks who are otherwise limited to VHF. For 
operational details, see Chapter 25 of Volume 2. 


The KaNode provides no networking capability. Thus, it is intermediate 
in "smarts" between the digipeaters described in section 3.C and the 
networking nodes described in the Chapter 9 and in the following 
sections of this chapter. 


Most KaNodes that the author has encountered seem to be dual 
frequency (two port). A few are single frequency. The following 
description applies to both except the comments concerning 
cross-connection between ports. 


10.A.1 WHAT A KANODE DOES: A KaNode allows you to connect to 
it. Then, you can ask it to connect you to someone or something else. 
Many also have mailboxes attached. The convention often seems to be 
that mailbox, node, and digipeater function have different SSID's (see 
sections 3.A.1, 3.B, 4.E concerning SSID's). The example of section 
3.B shows, in fact, a KaNode mailbox. 


10.A.2 HOW TO CONNECT THROUGH A KANODE: To connect to 
another node or station using a KaNode, you must connect to it first. 
Then, you ask the node to make the connection for you. To make a 


connection on the same frequency as that on which you arrived at the 
KaNode, you simply send C callsign where callsign is either an 
amateur call or a node name. For example, if you connected to a 
KaNode on VHF and wanted to connect to W1MM who's station is in 
connect range and on the same VHF frequency, you would simple type 
C WI1MM. The advantage of this method over using it as a digipeater is 
in error handling as discussed in section 3.D. 


If you connected to a KaNode on HF and wanted to connect to WIMM 
who's station is in connect range and on the KaNode's VHF frequency, 
you would simple type X W1MM When you wish to make a connect on 
the opposite frequency at that on which you arrived at the KaNode, you 
simply send X callsign. The "X" in this case means 
"cross-connect". 


An interesting and useful feature of KaNodes is the stay-connected 
option. This is particularly useful on HF with its frequent disconnects. 
What happens with the usual link failure (due to excessive retries, 
usually) is that the node recognises that there is no longer a good link. It 
then generates a disconnect message which ripples back to the user and 
produces the familiar *** DISCONNECTED on your screen. The 
stay-connected option stops the disconnect at the KaNode from which 
you connected using this option. You make this happen by adding a 
space and an § at the end of your connect request. 


10.A.3 Heard and Node lists: One of the common mysteries about 
KaNodes is how you find out what is there to connect to. Sending the 
node a J (for Just-heard) gives you a heard list. Depending on activity, 
the list may hold anywhere from a few minutes to 10 minutes of calls. 
Similarly, sending the node an N (for Nodes-heard) may give a list that 
is several days old in parts. 


Each of the two lists (J & N) indicate which of the two ports (if there is 
more than one) the station or node was heard. One of the confusion 
factors is that the ports are often listed with a V (VHF) or H (HF). If 
you have worked through several KaNodes, especially HF/VHF 
combinations, it may be difficult to tell which side of a KaNode you 
entered on. There is, however, an easy way. Since you are connected to 
the node, it must have heard you! When you ask for the Just-heard list, 
your callsign is almost always the last one (the most recent heard before 
sending you the list). Next to your call is a symbol showing the port on 
which you are connected. reaching any call or node with the same 
symbol requires a C because it is the same port; any call with a different 


symbol requires an X. 


Here is an example of a "J" list from a cross-band KaNode (shortened): 


NS8HEE-3/H 03/06/93 18:11:58 
K7MYU/V 03/06/93 18:12:47 
N700-3/H 03/06/93 18:12:51 
AZ/H 03/06/93 18:13:54 
N2EZH/H 03/06/93 18:14:04 
NOSNS-14/H 03/06/93... 182152752 
WD71I/H 03/06/93 18:15:54 
SALEM/V 03/06/93 18:16:33 
AF7S-1/V 03/06/93 18:18:20 
KA7EHK/V 03/06/93 18:18:21 
WGON/H 03/06/93 18:18:27 


WH6ANH-15/H 03/06/93 18:19:15 
KAT7EHK-15/V 03/06/93 18:19:22 
ENTER COMMAND: B,C,J,N,X, or 


And here is an example of a shortened "J" list from a KaNode with both 
ports on VHF: 


WB7SNH/2 00/00/00 00:03:28 
VE7DBZ-15/1 00/00/00 00:04:00 
SPR/1 00/00/00 00:05:05 
VE7PL/1 00/00/00 00:07:50 
VE7TPL-3/1 00/00/00 00:07:59 
K7TPN-8/2 00/00/00 00:08:24 
WB7SNH-15/2 00/00/00 00:10:33 
VETDIE/1 00/00/00 00:11:56 
VE7DHM-8/2 00/00/00 00:12:15 
PTIN/2 00/00/00 00:12:41 
W7LD-15/2 00/00/00 00:12:41 


VETDIE-15/1 00/00/00 00:12:47 
KA7EHK-15/1 00/00/00 00:12:48 
ENTER COMMAND: B,C,J,N,X, or 


Note the difference between port symbols! 


10.A.4 NOTES ABOUT HF: If you are going to use a KaNode with an 
HF port, take a look at Chapter 12 about HF operation. 


You should also be aware that the RF baud rate is usually lower (300 
baud instead of 1200) and packet lengths are much shorter. Thus 
packets come through in smaller chunks than you might be used to and 
they appear more slowly. 


The "hidden transmitter problem" (see section 3.E.2) is a way of life on 
HF. If you are in Washington and talking to a station in Colorado, there 
might be stations hidden (to you) in Texas or Brazil! 


There is a great variety of networking nodes (of all flavors), KaNodes, & 
TNCs which digipeat on HF. Operation is much less defined than on 
VHF. The best thing I have found is to experiment, experiment, and 
experiment some more! 


10.A.5 NETWORK-LEVEL ACTIVITY: Despite the appearance that a 
KaNode is simply a sophisticated digipeater, these nodes do utilize some 
network-level protocol (see Chapter 11). 


When a connection is requested to another KaNode, a circuit similar to 
that of a Net/Rom node is created. This circuit becomes a pipeline for 
your packets. It also has additional error correcting. This activity is 
entirely at levels 3 and 4 of the OSI Networking Model (see section 
11.B). 


10.B. TexNet Networks 


TexNet was developed by the Texas Packet Radio Society (TPRS). The 
two areas where this type of network seems to be in greatest use is in 
Texas-Oklahoma-Arkansas and in Michigan. TexNet nodes are 
described briefly in section 8.E.5. Here, we will focus on operation and 
use. 


The TexNet protocol hides network activity quite a bit (but not entirely) 
from users. Routing (that is destination table maintenance) is 
semi-automatic. 


10.B.1 Node services: TexNet nodes provide a slightly different set 
of services than is customary for Net/Rom nodes. Here is the list from a 
TexNet node near Oklahoma City, Oklahoma: 


Connect to the Weather Server 
Bye (Disconnect) 


L = List all known network LOCATIONS 

C W5ABC @ LOCATION = Connect to station at remote LOCATION 
C W5ABC VIA DIGI1,DIGI2 @ LOCATION = Connect via digipeaters 

C CQ @ LOCATION = Call CQ on user port at LOCATION 

S @ LOCATION = Get statistics report from LOCATION 

S Y @ LOCATION = Get yesterdays statistics 

M (@ LOCATION) = Connect to the Packet Message Server 
WwW — 

B = 


The Packet Message Server is a local mailbox which is programmed into 
the node as a mail server. When you ask for a connection to 

the mail server at your local node (or some other one), you are 
connected to the mailbox which has been pre-programmed for that node. 
These are generally not full service store-and-foreward bulletin boards. 


The Weather Server is a mailbox which is reserved for weather 
information. It is typically a regional mailbox devoted to weather 
bulletins. The same mailbox may be programmed for use by several 
nodes. To some packeteers outside the region where TexNet is in use, 
this may seem a bit superfluous. But, within this region, some of the 
United State's most severe weather (tornados) are found. Very fast 
dissemination of weather alerts is very desirable. Thus, the Weather 
Server can be very useful. 


One of the services which is not shown on this list is called alert. Alert 
is intended for emergency situations. When alert is turned on, any user 
who connects receives a message asking the user to disconnect unless 

the connect is related to the emergency. 


10.B.2 Making a connection: Like Net/Rom, you must know what 
node a particular user uses in order to connect. And, like Net/Rom, you 
connect to your local node first. As far as you are concerned, the 
difference (between Net/Rom and TexNet) is that you do not connect to 
the distant node before connecting to the distant user. Instead, at your 
local node, you type the command: 


C usercall @ nodename 


In one complete process, your connect request is routed to the node you 
specified with nodename and that node makes the connection to the 
station you specified with usercall . 


10.B.3 Routing: One of the features of TexNet is that users need not 
know the structure of the network. If a connection to a distant user is 
requested, it is naturally assumed that it will happen. How does it work? 


Though not shown in the abbreviated command list (section 10.B.1), 
there is a routes command which returns the routing table of the node to 
which you are connected. 


Network CMD ? 
ROUTE 


LOCATIONS served by the network are: 


173 000 000 000 000 CHOCTAW 172 172 001 000 075 OKEMAH 
162 172 002 000 075 MUSKOGE 161 172 003 000 075 MKOTST 
160 172 003 000 075 FTGIBSN 164 172 004 000 075 FAYETVL 
174 172 005 000 075 HOGEYE 175 172 006 000 075 GARFLD 
166 172 004 000 075 FTSMITH 165 172 005 000 075 CLAYTON 
176 172 007 000 075 OARSMO 046 172 006 000 075 SHERMAN 
169 172 004 000 075 TULWX 105 172 016 000 075 FLORES 


Network CMD ? 


The preceeding table may be interpreted as follows: the first column 
before each node name is the identification number of the node. The 
second column is the node number of the neighbor which has the best 
route to the given node. The third column is the number of hops to the 
given node. The fourth column is the node number of the neighbor with 
the second-best route to the given node. The fifth column is the number 
of hops via the second-best neighbor to the given node. 


A quick survey of the table should show how it works. Look first at 
CHCTAW (the 6-character AX.25 alias for the node CHOCTAW), the 
node which provided the route list. It is node number 173 and there are 
no neighbors with a route to it (not a suprise!) Then look at the entry 
for OKEMAH on the top line. It is node number 172. It shows that the 
neighbor with the best route to OKEMAH is node number 172 and there 
is only 1 hop involved; one can infer from this entry that OKEMAH is a 
direct neighbor of CHCTAW. All other nodes in this table specify route 
through node 172 (OKEMAH). Thus, one can also infer from this that 
OKEMAH is the only neighbor (to CHCTAW)! 


Further, MUSKOGE, node number 162 on the second line, is only 2 
hops away and, like all of the others, must go via node 172. We can 
infer from this that MUSKOGE is a neighbor of OKEMAH. Since it is 
the only 2-hop node, it must be the only neighbor of OKEMAH. 


What is not apparent from the preceeding discussion is how the routing 
tables are maintained. There is both an automatic route management 
system (somewhat like Net/Rom) and a Network Management System 
(NMS) which frequently (every 10 minutes) surveys nodes. If any node 
fails to respond, routing tables in other nodes are modified. The NMS 
also maintains data about retry rate, node usage, etc. Thus, routing 


tables are fully automatic in the Net/Rom sense but have an have an 
over-riding management system which deals with wide-area routing. 
The NMS helps to resolve the problem of the slow propagation of 
network changes; the NMS makes the changes network-wide much 
more quickly. 


10.C. ROSE Networks 


The ROSE network was developed by the Radio Amateur 
Telecommunications Society (RATS) in New Jersey. It is even more 
different from Net/Rom than is TexNet. Node naming and addressing is 
completely different and so is the method of making a connection. As 
mentioned in section 8.C, the convention in ROSE networks is to refer 
to nodes as switches. 


ROSE networks are quite wide-spread in the Eastern United States. This 
network extends east of the Mississippi River to the Atlantic Ocean and 
from New York south to about Georgia. It extends westward into 
Oklahoma and Texas. There are also some isolated ROSE networks. 
One of which the author is aware is around Edmonton, Alberta, Canada. 


10.C.1 Switch services: In comparison to other networks, the 
services provided by switches, themselves, is very limited. Most of the 
services which are found within Net/Rom networks are outside of ROSE 
networks. It is unusual, for example, to find a bulletin board which is an 
actual part of the network. That does not mean that such services are 
missing. Instead, they just are not an integral part of the network. This 
is a consequence of the network philosophy rather than any deficiency in 
the network, itself. 


One can get information about how to use ROSE switches by 
connecting to a local switch. The switch returns a fairly detailed 
message. An incomplete example follows: 


ROSE X.25 Packet Switch Version 3.2 (930303) by Thomas A. Moulton, 
W2VY 
SERVING THE EL RENO METRO AREA 


This ROSE switch is located in El Reno OK. Its call is AC5C-5. 
frequency is 145.07 
Its address is 405262. Its digi call is AC5C5 Connect to stations 
in the El Reno area with the command: 

C CALLSIGN V AC5C-5, 405262 
Connect with stations in other areas by using the ADDRESS of ROSE 
switch in 


that area instead of my ADDRESS. For example, to connect to 
"SOMEONE" in 
Pauls Valley, use the command, 
C SOMEONE V AC5C-5, 405238 
Switches currently available on the ROSE network include: 


Oklahoma: Texas: 
405226--ARDMORE (WA5YOM-5) 214050--DALLAS (TEXNET) (N5BCA-6) 
405238--PAULS VALLEY (WB5CQU-5) 214223--DALLAS (N5DT-3) 
405248--LAWTON (WJ5Y-5) 214234--NORTH DALLAS (N5BCA-2) 
405262--EL RENO (AC5C-5) 214555--ROSE NETWORK NEWSLETTER 
405444--VELMA (KA5ZZI-5) 409598--CENTER (WB5RIA-2) 
405732--MIDWEST CITY (K5JB-—5) 409845--COLLEGE STATION (W5AC-2) 
405771--SPENCER (NOELS-—5) 713453--HOUSTON (W5FCN-2) 

713592--CLEVELAND (W5DN-2) 
Louisiana: 817491--DOUBLE OAK (WB5 


10.C.2 Making a connection: The method of making a connection is, 
to users, perhaps one of the most distinguishing features of ROSE 
networks. 


Unlike Net/Rom or TexNet, one does not connect to the switch in order 
to connect to another station. Instead, a connection request is made as 
if the switch is a digipeater (using "via"). This method was apparently 
chosen in order to conform to AX.25 connection rules which are built 
into standard TNCs. According to AX.25, there are only two methods 
of connecting: either directly to a specified callsign or through 
digipeaters to a specified callsign. It is possible to use UI packets to 
carry messages without connecting (as in TCP/IP; see Section 10.D); 
but without special software, doing it is not easy. 


The method for connecting to another station through a ROSE packet 
switch is: 


C callsign V localswitch, distant switch 


Of course, callsign is the call of the station you wish to reach. 
Localswitch is the callsign of the local ROSE switch, not its name. But 
distantswitch is the name, not the callsign, of the switch where you 
expect to find the station you are connecting to. This format is 
completely acceptable to any AX.25 TNC since it fits the format of 
connecting through a digipeater. 


It is a little confusing when you wish to connect to someone who uses 
the same switch as your local one. In this case, localswitch and 
distantswitch refer to the same switch! But different characters need to 
go into these two slots and both slots must be filled. For example, if one 
were in Houston, Texas and wanted to connect to a local user, say 


W5XX, on the ROSE switch (see list, above), one would enter 
C W5XX V W5ECN-2, 713453 
Note that WSECN-2 and 713453 are the same switch. 


10.C.3 Packet Switch addressing: To users of Net/Rom and TexNet 
networks, the addressing convention used by ROSE may be rather 
perplexing. In concept, however, it is quite simple. Names of switches 
are taken from telephone practice. The first three characters are the 
telephone area code of the area served by the switch. The last three 
characters are the telephone prefix of the area served by the switch. A 
switch may be set up to recognize a whole set of area codes or prefixes. 


ROSE developers have indicated a desire to extend the addressing 
mechanism to complete telephone numbers with international routing 
prefixes. If this comes to pass, one could theoretically connect to 
another packet station just knowing its telephone number. 


10.C.3 Routing: As can be seen from the description of the 
connection process, no knowledge of network structure is needed by 
users. In fact, it is not only not needed but hidden. 


Despite the network structure being hidden, it works much like the other 
networks which have been described in this chapter and in Chapter 9. 
There are routing tables in each switch. But these tables are completely 
manual. That is, it takes direct action by the node operator to change the 
table. Thus, if a section of the network were to fail, there is no 
automatic adaptability. Routing is changed to accommodate such 
failures only when someone notices that it has happened. 


10.D TCP/IP Networks 


In this section, we will focus on the network aspects of TCP/IP. For 
other information, see Chapter 15. 


Operation of TCP/IP networks can be very confusing to someone who's 
packet experience is mostly with one of the other network types 
discussed in this chapter and Chapter 9. The entire process is different, 
starting with the basic exchange of packets. There are no TNCs 
designed for radio TCP/IP (that the author is aware of, anyway). 
Regular TNCs work, but only when operated in KISS mode (where a 


computer does most of the real work). Thus, you cannot use generic 
terminal programs; you must use something like NET or NOS. 


10.D.1 Packet exchanges: With TCP/IP, the familiar connection 
never occurs. Instead, a scheme called datagram is used. If the stations 
exchanging packets are local (that is, they can hear each other), each 
one sends UI packets (which still contain a destination callsign). These 
packets carry all of the message information including requests to resend 
error packets. The conventional AX.25 scheme uses special packets to 
represent each of the special conditions (information, connect, 
disconnect, etc); see Section 4.D for more information about packet 


types. 


In a sense, TCP/IP uses a generic [UI] AX.25 packet for almost all 
transactions. All of the action is in the text portion of the packet. 


10.D.2 Network architecture: As with other protocols, there is 
typically a local network linked with other local networks. Because of 
the large quantities of information often tranferred (such as program 
files), local network baud rates are often higher than 1200 baud; there 
are some local networks with baud rates up to 56Kbaud. TCP/IP 
networks are subject to all of the constraints discussed in Chapter 8. 


One significant difference is that with the standard TCP/IP software, 
every station can also be a node. Thus, messages may be routed 
through a whole set of stations (a bit like digipeating, but with all of the 
error correction which nodes offer). While this operation reduces the 
efficiency of a local network, it does work. 


10.D.3 Addressing: Addressing is discussed in much more detail in 
Chapter 15. The important feature to note here is that TCP/IP stations 
have an Internet-style (or IP) address. It consists of four numbers, each 
in the range of 0-255 (readers knowledgeable about the inner workings 
of computers may recognize these as 8-bit numbers so that the entire 
address is a 32-bit number). 


Each TCP/IP station has an address, sometimes more than one. For 
hams, the first number of their address is 44. This designates the 
amateur network. Thus, all ham IP addresses are of the type 
44.xx.yy.zz. The middle two parts of the address are generally 
associated with a specific physical location. The last part is associated 
with a specific machine. Actually, if a machine joins several networks, 
there is a separate address for each connection to that machine. 


10.D.4 Local Routing: Routing is one of the big distinctions between 
TCP/IP and the other AX.25 protocols discussed so far. Suppose that 
you are in an area where the addresses all begin with 44.10.3 (just to 
pick a nearly random set of numbers). Suppose that your IP address is 
44.10.3.17 and you want to send a message to 44.10.3.102. There are 
several ways this might happen. 


You may already know that 44.10.3.102 is KA6PDQ-3 who is operating 
as part of your local network. In this case, the IP address and the 
corresponding call would be entered into a lookup table in your 


computer. Then the UI packets from your station will be labeled to 
KA6PDQ-3 and from you. 


Suppose that you don't know the call of 44.10.3.102. Before sending 
message packets, your station needs to find the callsign of the 
destination station. Your station then sends a UI packet which has a 
special set of characters in the message identifying it as an ARP 
(Address Resolution Protocol) packet. This packet essentially says "is 
the station 44.10.3.102 out there, and if so, what is its callsign?" If 
44.10.3.102 can hear your station, it will answer [again, with a UI 
packet] "Iam 44.10.3.102 and my callsign is KA6PDQ-3." Once your 
station receives this response, it can begin sending packets. 


10.D.5 Wide-Area Routing: Routing outside your local area takes 
place through a gateway. Gateway is the generic name in TCP/IP 
networks for a station with ports on different networks. In otherwords, 
a gateway is a like a node-stack (but is more general since it includes 
wire and other links to other kinds of networks). How routing is 
handled depends on the relationship between addresses and network 
construction in a particular area. 


Suppose that a network is addressed hierarchically. This means that all 
stations have some part of their address the same when they use the 
same local network. For example, everyone on one local network might 
have an address 44.10.3.xx and all those on a neighboring local network 
might have addresses 44.10.5.xx. In this case, everyone on the 44.10.3 
network would have programmed into their computers the fact that all 
messages destined for an address 44.10.5.xx would be sent to the 
gateway which has a route to that network. The gateway would have 
programmed how to route all of those messages to the station which is 
the gateway to the 44.10.5 network. 


A flat network is one in which there is no relationship between network 
structure and addresses. In this case, there might be some with 
44.10.3.xx addresses on one local network and others with addresses 
44.10.3.xx on another local network. In this case, there must be 
individual routing instructions for every station in each of the networks! 


In either case, a message destined for a TCP/IP station outside the local 
network begins as UI packets. The header includes the callsign of the 
originating station and the callsign of the gateway. The body of the 
message then must include the address of the destination so that the 
gateway (and any other stations along the way) know how to route the 
message. 


In the case of a message destined for a very distant destination, the 
originating station must be programmed with the gateway to which the 
message is handed. In many local networks with only one gateway, the 
choice is obvious. Decisions are then made at various points within the 
network. These decisions might be of the form "all messages addressed 
to 44.89.xx.yy" will be directed to the neighbor handling messages to the 
north, etc". Since the second number in the address is often associated 
with states, or large sections of states, these decisions can be fairly 
comprehensive. 


Lest one develop the opinion that wide-area routing is primarily manual, 
it should be said that there are several protocols developed for TCP/IP 
networks which perform automatic routing. One of the most widely 
used is RIP, (Routing Information Protocol). This involves periodic 
routing broadcasts by gateways (reminiscent of Net/Rom routing 
broadcasts). Another is RSPF (Radio Shortest Path First). The gateway 
software must include one or the other of these in order to make them 
work. This is seldom a problem with computer-based gateways but can 
be at hilltop sites. 


10.E FlexNet Networks 


The author has no first-hand information about FlexNet networks. As 
soon as it is possible, more information will be included. 


10.F SUMMARY 


Chapter 10 has investigated a number of the non-Net/Rom networking 
protocols. 


KaNodes are included in this chapter primarily because they are not 
Net/Rom. But, they are also, for all practical purposes, not networking. 
KaNodes are connection servers in addition to supporting mail boxes. 
Many KaNodes are dual frequency and the version most popular with 
other users is the kind with one port on HF and the other on VHF. This 
arrangement gives VHE users access to HF which they would not 
otherwise have. 


TexNet is a network protocol popular in Texas/Oklahoma and in 
Michigan. Network operation is generally hidden from users but it is 
possible to discern some of its structure. Maintenance of routing tables 
is automatic; the automatic processes is augmented by one or more 
stations in each network which is a routing manager. This station 
periodically probes the network and updates the node routing tables 
accordingly. The use of the routing manager speeds system adaptation 
to node changes. 


ROSE switches utilize a connection procedure which differs entirely 
from any of the other nodes. One does not even connect to the node for 
a normal user connection. Instead, it is used as if it is a digipeater. 

Node names are taken from telephone area codes and prefixes. 


TCP/IP uses network techniques developed for wired computer 
networks. They are quite different from our more common packet 
procedures and require special computer programs. AX.25 is still, 
however, the method used to carry the basic information. 


FlexNet nodes are found throughout many of the countries in Europe. 
The author does not have sufficient information to provide operating 
details. 
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AX.25, the common amateur packet radio protocol, is borrowed from 
the commercial packet switching protocol named X.25. This number is 
simply a catalog designation for this particular international standard. 
AX.25 is the AmateurX.25. AX.25 differs in some important details. 
One of these details is that X.25 has a network master to control 
operation. Since this was considered unacceptable for ham use, a 
masterless (also called peer-to-peer) version was developed for AX.25. 
Also, addressing was changed to meet ham legal requirements. 


11.A WHAT IS A PROTOCOL? 


The author's "American College Dictionary", 1957 edition, defines 
protocol as: 


pro-to-col, n. 1. an original draft, minute, or record from which a 
document, esp. a treaty, is prepared. 2. a supplementary international 
agreement. 3. an agreement between states. 4. an annex to a treaty 
giving data relating to it. 5. the customs and regulations dealing with 
ceremonies and etiquette of the diplomatic corps and others at a court 
or capitol. 


Definition 4 comes perhaps the closest to the current technical usage of 
this word. A useful way of thinking about it might be to think about 
sports. Sports protocol is what is written in the referee's rule book. But 
in each sport, there is also a lot tradition. In U.S. football, for example, 
there are the cheerleaders, the equipment, the coaches & trainers, and so 
forth. Most of this is not written about in rules books but is, none the 
less, part of the sport. 


So, also, is it in amateur packet radio. AX.25 is the formal name of the 
protocol but there are a lot of other things which are thought of as 
packet radio which really are not part of the AX.25 rule book. 


Actually, AX.25 defines only a very small portion packet operation. We 
will see how small a portion it is and how it fits with many other parts 
which are often not formalized or agreed on. 


11.B. THE "LAYER" MODEL 


There is a model (a way of visualizing) which is becoming popular in 
networking. It is called the ISO OSI Reference Model. ISO stands for 
International Standards Organization. OSI stands for Open Systems 
Inter-connection. Many refer to this as simply The Layer Model. It is 
really a framework or outline to which digital data transmission systems 
can be fitted. Some schemes fit this model pretty well and some, not so 
well. AX.25 is not too bad as long as it is recognized that it fits only a 
small part of the model. There is a diagram which is usually used to 
illustrate this model. It is shown in Figure 11-1. 


7. APPLICATION 7. APPLICATION 
6. PRESENTATION 6. PRESENTATION 
5. SESSION 5. SESSION 

4. TRANSPORT 4. TRANSPORT 

3. NETWORK 3. NETWORK 

2. LINK 2. LINK 

1. PHYSICAL 1. PHYSICAL 


FIGURE 11-1, LAYER MOL 


The layer model is important because it defines a way of organizing the 
computer programs which do packet radio (a TNC is, after all, just a 
special-purpose computer). When the programs or processes are 
organized this way, we start to see that: 


(a) a Physical Layer does not "care" what the "bits" represent; it 
simply provides a mechanical means for moving those bits from one 
place to another. 


(b) a Link Layer does not "care" how the bits are moved. It simply 
constructs the packet and hands it to the Physical Layer for 
movement. 


(c) The Network Layer does not care how links are established. It 
tells the Link Layer to make a connection. It has a standard message 
format which it hands to the Link Layer for sending. 


(d) Each higher layer, where it is implemented, simply passes the 
message to the next lower layer, expecting that that layer will move it. 
And that layer, passes it to the next, expecting the same, until it 
reaches the Physical Layer where it finally gets moved. The same 
happen in the opposite order at the receiving end. 


11.C. ALAYER MODEL STORY 


In several earlier chapters, primitive telephone systems where used to 
simplify the ideas of connections and routing. Here, we will use another 
metaphor - a pair of mythical, not-too-long-ago, armies - the Grey 
Army and the Light-Black Force (that's right, they are difficult to tell 
apart). These armies have been at war for some time for control of the 
region where they live. Lets zoom in on one portion of each army, the 
Grey Message Corps and the Light-Black Dispatch Service. Please 
accept my apologies about the male-only characters in this little story but 
in this time not-too-long-ago, almost all soldiers were male! 


11.C.1 Runner-Privates: These armies (being somewhat long ago) 
used runners (Privates, of course) to carry messages between units. 
Now, these runners really do not care what the message is. They care, 
thought, about some pretty fundamental things, like - is it small enough? 
- does it have far go? - is it very heavy? In this, the two armies are 
really no different. 


11.C.2 Command-Post Corporals: In both armies, Corporals are in 
charge of getting messages moved between command-posts. Corporals 
in adjacent command-posts have to agree on how messages are to be 
exchanged. 


The Grey Message Corps has chosen a rather elaborate system of 
message pouches. They have agreed that green pouches are to be used 
to make initial contact between neighboring command-posts. Red 
pouches are to be used to end contact. White pouches are for general 
messages. Yellow ones are sent back to the post which sent a pouch 
when a white (information) pouch arrives so badly damaged that a new 


one is needed to replace the original. The pouches have a handy place 
on the outside for writing where it is from and where it is going to. The 
white (information) ones also have handy numbers so that the 
destination can tell if any have been lost. The Corporals, of course, are 
responsible for writing the destination and origin information on the 
labels on the outside of each pouch. 


The Light-Black Dispatch Service, on the other hand, has chosen to 
make it as simple as possible for the Corporals. There are no fancy 
colored pouches here! There are just some nondescript beige ones 
which have a label for the origin and destination. The Light-Blacks have 
decided that they will just send messages without all of the business of 
making and terminating communications. 


We now have the two foundation layers for a pair of mythical 
communication systems. The Greys use theirs like this: The Corporal in 
command-post Charlie is told by his Sargent that he had better start 
sending plans (for tomorrow's action) to their neighbors to the north, 
command-post Bravo. The Corporal gets out a green pouch, and writes 
on the outside "to Bravo from Charlie" and gives it toa runner. The 
runner, having been told to go north to find command-post Bravo, sets 
out. But part-way there, he steps on a land-mine and is never heard 
from again. The Corporal at command-post Bravo does not even know 
that anything has happened except for the dull thud off to the south 
when a land-mine went off. The Corporal at command-post Charlie 
waits for a reply and, when none arrives, decides that it is necessary to 
try again. So he gets out another green pouch, addresses it again, and 
sends off anew runner. This runner makes it to command-post Bravo 
and hands it to the Corporal there. This Corporal does not have to look 
in the pouch; he sees that it is green, that it is addressed to his 
command-post, and that it is from command-post Charlie. He gets out a 
brown pouch (agreeing to begin exchanging messages) and addresses it 
to command-post Charlie from Bravo. A runner carries the pouch back, 
thus signaling that it is ok to proceed. Once this exchange is complete, 
the Corporals at each command-post tells his Sargent that the message 
can proceed. 


On the other side of the line, the Light-Black Sargent of Dispatches at 
command-post Beta decides that it is time to send a message with 
tomorrow's plans to command-post Alpha. He simply gives the message 
to his Corporal with the instructions to send it. The Corporal places the 
message into a convenient beige pouch, addresses the pouch, and passes 
it to arunner with directions. The Corporal makes no decisions about 


success or failure of the message exchange; that is the responsibility of 
his superior officers! 


There is more than just a difference in style here. The Greys, being 
populists, believe in making decisions at as low a level as possible. 
Thus, their Corporals are given lots of responsibility. The Light-Blacks, 
on the other hand, are believers in centralized decision making and 
choose to make as simple as possible for their Corporals. 


11.C.3 Command-Post Sargents: In both armies, Sargents are 
responsible for managing links with neighboring command-posts. Of 
course, how they go about it differs in the two armies. 


The Greys think of the communication system among command-posts 
as a network. The Sargents are responsible, among other things, for 
determining which neighboring command-post to send a message which 
is really going to a location many command-posts distant. For example, 
command-post Charlie may have a message for command-post Zulu. 
The Sargent, who keeps track of such things, knows to send messages 
for Zulu to the neighbor Romeo, because Romeo sent out a general 
bulletin not long ago that it has a way to send messages to Zulu. When 
command-post Charlie wants to send a message to Zulu, the 
command-post Message Corps Sargent instructs his Corporal to send a 
special message to command-post Romeo. The Corporal, of course, 
does not care what the message is but it will request Romeo to "set up a 
circuit" to Zulu. When the Corporal receives this message, he first goes 
through the exercise of establishing communication with command-post 
Romeo, its neighbor to the South. This is done, if you will recall, by 
exchanging colored message pouches. Once communication is 
established, the Corporal at Bravo tells his Sargent that it is possible to 
proceed. The Sargent gives the "set up a circuit" message to his 
Corporal who places it into one of his (white) pouches and sends it off 
to Romeo. When it arrives successfully at Romeo, the Corporal there 
removes the message from the pouch and passes it to his Sargent. The 
Sargent says, "Hey, we can send directly to Zulu!" So he, in turn, writes 
a "set up a circuit" message and directs that it be sent off to Zulu. He 
passes it to his Corporal who goes through the same process, but this 
time with Zulu. Once established, a message goes back to Bravo, saying 
that the circuit is established. The Sargents in the three command-posts 
(Bravo, Romeo, and Zulu) control this circuit. The Corporals take care 
of the sending details and the Privates run the messages between the 
command-posts. 


Light-Blacks, on the other hand, have a slightly different concept of their 
network. The Sargents keep a list of where to send messages for 
different destinations. In some cases, it is based on best guesses. In 
other cases, it is based on the last time the Sargents of the Light-Black 
Dispatch Corps got together for one-too-many beers. These lists are 
often kept on rumpled scraps of yellow sticky-pad which sometimes fall 
off the wall where they normally hang. So it is when the Sargent at 
command-post Beta finds that it is necessary to send a message to 
command-post Omega. He finds one of his pieces of yellow sticky-pad; 
it has written on it that messages for Omega should be sent to 
command-post Rho. He addresses the message to Omega but tells his 
Corporal to send it to command-post Rho. The Corporal puts the 
message into one of their beige pouches and sends the runner on his 
way. When it arrives at command-post Rho, the Corporal there passes 
the message to his Sargent, as every good Corporal should. The Sargent 
sees that the message is really addressed to command-post Omega so he 
gives it back to the Sargent with instructions to send it on to Omega. 
The Sargent does not know that this message is the same one he just 
received; to him, it is just another message and he sends it on its way. 


11.C.4 Command-Post Lieutenants: In both armies, Lieutenants 
keep track of message movement reliability. They attach various checks 
to the messages received from their superiors. These checks are then 
used at the other end to verify that messages are received in the right 
order and without error. In principle, the checks are quite similar in the 
two armies. They choose to do them just a little differently but the 
differences are small enough that we need not examine them in detail. 


What is important is that the Lieutenants receive messages from their 
Captains, add the error-checking to them, then pass them on to their 
Sargents for sending. On receiving a message, the Lieutenants remove 
all of the extra error-checking and pass the clean message up to their 
Captains. Their superiors need not know anything of message passing 
problems, it is all hidden from them. 


11.C.5 Command-Post Captains: In both armies, Captains are 
responsible for managing message-passing sessions. In other words, 
this means that if there are messages are moving several ways at a time, 
the proper message gets sent toward the right destination. These 
captains are also responsible for handing messages from their Captains 
to their superiors, the Majors. 


11.C.6 Command-Post Majors: In both armies, Majors deal with 
presentation of messages. In both cases, the messages may be rewritten 
on standard message forms. However, the forms are only vaguely 
similar in the two armies. But in each army, the forms are easily 
recognized. 


11.C.7 Command-Post Generals: In both armies, the Generals being 
like Generals, the world over, are directors of action or application. In 
some cases, the Artillery Generals are interested in sending and receiving 
special messages of importance to their artillery units. So their messages 
have information about targets, winds, and such. The Airplane Generals 
are interested in things like targets, anti-aircraft batteries, and storms. 
The Supply Generals are interested in things like food, cots, boots, and 
spare bayonets. The standard messages are a little different for each 
and, of course, the two armies do things a bit differently. But the 
principle is that a General is responsible for each application. 


When a General, say the General of Supply, wishes to send a message to 
another General of Supply, he passes it to his Major who makes sure the 
message has been written on the proper form. He then passes it to his 
Captain who begins a new session (if this is not a continuation of an 
existing one). He, the Captain, passes it to his Lieutenant who adds the 
necessary error verification. The Lieutenant then passes it to his Sargent 
with instructions for sending. The Sargent, as described earlier, goes 
through the actions appropriate for his army, to get it sent. At the other 
end, the message ripples back up through the chain-of-command to the 
General of Supply who can do something with the message. 


11.C.8 Cutting through red tape: The Greys, particularly, seem 
burdened by lots of red-tape, especially in making and breaking 
communication with other command-posts. But every once in a while, a 
different runner arrives. This runner is from the "Grey News", the 
newspaper serving the the populace which supports the Greys. Being 
civilian, the Grey News folks want to get to the real source of the news, 
the General. As a concession to their supporters, the Grey Message 
Corps has made it possible for the inquiries from the News to bypass all 
of the Lieutenants, Captains, and Majors, and go directly to the General. 
This makes for much better local support and still allows the Grey Army 
to (generally) do things the way they want to. 


11.C.9 Comments: These two "armies" represent the AX.25/NetRom 
and the TCP/IP world. If there is any question, the Greys are the 
NetRom folks and the Light-Blacks are the TCP/IP people. Each 


command level corresponds to one of the layers in the Layer Model. 


11.D. AX.25 & THE PHYSICAL LAYER 


The physical layer describes the physical mechanism for getting "bits" 
from one place to another. THIS IS NOT PART OF AX.25! We are 
left to our own devices for moving those bits. But, over the years, a 
whole set of customs has grown up and they have come to define how 
those bits get transported from one place to another. 


For example, the use of BELL-202 modem tones (1200Hz and 2200Hz) 
as the standard tones for AFSK modulation is the standard for VHF. On 
HF, the standard tones are 1600Hz and 800Hz. AX.25 never refers to 
this. Likewise, we tend to think of AFSK as standard. However, a 
modulation scheme called biphase is used on many of the packet 
satellites. Packet satellite modems are available for many of the TNCs 
with modem disconnect headers (see Vol 2-CH22: Connecting TNCs to 
Radios for other comments about modem disconnect headers). 
Similarly, direct FSK is commonly used at baud rates above 2400. 


It is clearly up to system builders to define the physical layer 
characteristics for various parts of packet systems. It should also be 
fairly clear that that once bits get moved through a physical layer, it 
should make no difference to other layers how the bits were moved. 
Likewise, to the physical layer, it makes no difference what the bits 
represent. 


11.E. DATAGRAMS AND VIRTUAL CIRCUITS 


At lower levels, one of the biggest distinctions between AX.25 and 
TCP/IP is the use of datagrams as compared to virtual circuits. We 
should not, however, limit our investigation to TCP/IP because ROSE 
and TexNet (see Chapter 10) both use datagram-based communication 
for movement of packets between nodes or switches. Here, as 
elsewhere in this book, the term Net/Rom will be used to refer to Level 3 
and Level 4 for AX.25; this term should be understood to apply equally 
to G8BPQ, TheNet, JNOS, and MSYS nodes. 


11.E.1 Virtual Circuits: In a Net/Rom network, a link between nodes 


(whether immediate neighbors or not) is set up and tested (by the nodes, 
themselves) before passage of user information proceeds. Once 
established, there is error-checking between the end nodes. 


To clarify this a little further, suppose that a user is connected to a node 
named PODUNQ. She wishes to talk to a friend at a node names 
WAYFAR. In between, there are nodes named (in order from 
PODUNQ) HILTOP, BIGCTY, MOUNT, KNOLL, VALLY, & 
CENTRL. Because of the way this network happens to be set up, our 
user as PODUNQ cannot just type "C WAYFAR" and have a successful 
link. Instead, by experimenting, she has found that it works pretty well 
if she types, instead "C BIGCTY", then "C KNOLL", then "C WAYFAR". 


When the connection request to BIGCTY is made, a circuit is set up 
from PODUNQ through HILTOP to BIGCTY. This is the first of three 
circuits which are generated. Until the circuit is broken (by a link failure 
or a disconnect request), error checking and correcting happens 
between PODUNQ and BIGCTY. Once the connection to BIGCTY is 
made, the connection request for KNOLL is acted upon by BIGCTY. It 
sets up a circuit from BIGCTY through MOUNT to KNOLL. This is the 
second circuit. Error correction now also happens between BIGCTY 
and KNOLL. Once the connection to KNOLL is made, the connection 
request for WA YFAR is acted upon by KNOLL. It sets up a circuit 
from KNOLL through VALLEY and through CENTRL to WAYFAR. 
This is the third circuit. Error correction now also happens between 
KNOLL and WAYFAR. Recognize that the error correction referred to 
in this paragraph is on top of the packet-by-packet error correction 
which is built into Level 2 of AX.25. The circuits of the kind referred to 
here are called virtual circuits. Note that there is no mention here of 
how one node knows which neighbor to use for a circuit to another 
node which is not a neighbor; that is also part of the Net/Rom protocol 
but does not relate in any way to the issue of circuits vs. datagrams. 


11.E.2 Datagrams: In TCP/IP networks and the other networks 
mentioned previously, datagram message transfer occurs. Lets suppose 
that our previous example of nodes PODUNQ, HILTOP, BIGCTY, 
MOUNT, KNOLL, VALLY, CENTRL, & WAYFAR are part of a 
datagram network. Lets further suppose that this network is like TexNet 
such that users can connect to the nodes in AX.25 style but that 
datagrams are used between the nodes. 


The first notable difference between this network and the Net/Rom one 
just described is the method for setting up the link between PODUNQ 


and WAYFAR. The way these networks are set up means that the 
intermediate connections are not likely to be needed. PODUNQ simply 
sends off the first information packet to HILTOP. The packet is 
addressed immediately to HILTOP but it also contain characters which 
say the final destination is WAYFAR. 


HILTOP sends it on to BIGCTY. To do so, it changes the immediate 
address of the packet to BIGCTY without changing the final destination. 
Each packet has not only the user information and final destination but 
other characters added by PODUNQ. These characters are for error 
correction by WAYFAR. If some packets arrive at WA YFAR damaged 
or some are lost, it is up to WAYFAR to request a repeat of those 
packets. 


If one of the nodes in unable to deliver a packet to the next node in the 
chain, one of several things might happen, depending on how the 
network is designed. In some systems, the user might never know 
(except for missing notification of receipt from WAYFAR). In other 
systems, the user could be notified by the node which could not move 
the packet onward. It might, however, take some time. 


BBS-to-BBS mail forwarding is in datagram style. Mail is forwarded 
from one BBS to another. It may take minutes, hours, or days to move 
from one to the next. The sender is never notified of this fact. Nor is 
the sender notified if one of the BBSs has a computer crash and the 
message is lost. Delivery is determined only if the addressee happens to 
send a reply (which our social protocol does not demand). 


In datagram packet transport, the reliability depends on cooperation 
between the two end-points in the exchange, not on the system in 
between. It's not that efforts to produce a reliable transport system are 
useless. It is simply a recognition that no network likely to be built is 
perfectly reliable. 


11.F. SOME EXAMPLES OF PACKET PROTOCOL 


Lets now look at how some of these protocol ideas and the Layer Model, 
in particular, actually fit some of the things we experience as packet 
radio operators. 


11.F.1 Operating with a TNC & Terminal: Basic packet operation 
with a TNC or its equivalent is probably the single most common packet 
radio activity. A TNC takes care of Layer 2 and part of Layer 1 of the 
Layer Model. The TNC defines the structure of a packet and the 
connection procedure to other AX.25 stations. The TNC also defines a 
lot of the characteristics of the modulation used by Layer 1. The radio 
defines whether the modulation is FSK or AFSK, & whether it is Single 
Side Band or Frequency Modulation. 


For all practical purposes, none of the higher layers are present. The 
TNC simply delivers text characters to the terminal which displays the 
characters. The TNC receives characters from the terminal moves them 
directly to Layer 2. 


11.F.2 Operating with a TNC & Advanced Terminal Software: 
Advanced terminal software such as LanLink and KaGold provide some 
of the features of higher Layers. The layers in between are missing, 
however. Still, the ability to manage sessions & move mail automatically 
should not be discounted. TNCs with auto-forwarding mailboxes fall into 
a similar category. 


Use of software with file-transfer procedures (X-Modem, Y-Modem, 
Z-Modem, Kermit, YAPP, etc. see Chapter 14) have some of the upper 
layers managed within these procedures. 


11.F.3 Net/Rom-type Nodes: These nodes have (at least) three modes 
of operation. One provides through-routing for circuits between other 
nodes. When operating in this way, only Layer 1, Layer 2, Layer 3, and 
Layer 4 are used. All 4 of these layers are implemented within the node 
software. 


When a station is connected to a node directly as a local user, the low 2 
layers are used. If the user asks for information from the node (such as 
a user list), the request is passed to higher layers which provide the 
response. Each such connection is a session. 


If a local user requests a connection to another node or if a distant user 
connects through network links, then, at the very least, Layer 3 and 
Layer 4 come into play. 


11.F.4 BBS with Node Shell: These stations have, perhaps, the most 
complete and obvious implementation of the full layer model. Layer 1 
and Layer 2 provide the physical link to other local stations. Layer 3 and 


Layer 4 (which rely of course, on the lower layers) provide network 
linking. Each connection to the bulletin board represents a session. 
Each session is capable of doing very close to the same thing, to all 
appearances simultaneously. The display of information including 
prompts, message lists, and the messages themselves, are all part of 
Layer 7, the Application Layer. 


11.F.5 TCP/IP Stations: These stations, whether a user station or a 
BBS, have a similar layer implementation. In general, however, more of 
the layers are operating in the typical TCP/IP home station than they are 
in a standard AX.25 station. Because of the protocol differences, the 
software built into a standard TNC must be bypassed. Other software 
often present in a TNC (called "KISS") is used. This software permits 
the computer connected to the TNC to make the TNC do what the 
computer wants, rather than what the TNC wants. 


11.G. PACKET PROTOCOL SUMMARY 


The concept of a packet protocol is not particularly easy to explain. One 
way of visualizing the idea uses the ISO Layer Model. This model 
describes a (digital) communication system in the form of independent 
processes. The lowest level one is responsible for moving bits from one 
place to another without regard to what the bits mean. Then next layer 
describes how the bits are organized (in our case, into packets). The 
next two layers describe the methods by which stations are linked 
together into a network. In all, this model has 7 layers. The situation 
where the layering is perhaps the most obvious is in a bulletin board 
(BBS). 


There are two common protocols used by hams for moving packets. 
One is AX.25 protocol which describes how connections are made, 
information is passed, and connections are broken. The other protocol 
is TCP/IP which uses a method without connections (called datagram or 
connectionless packets). 
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OPERATION 


Perhaps you have just gotten yourself a new HF radio and have an urge 
to try packet on the lower frequency bands. Maybe you have a 
Technician class license and want to try packet on 10 meters. This 
chapter attempts to provide information for you to get started without 
making too many big errors. 


The author is not an expert on HF packet. He has operated on HF 
through some VHF/HF gateways (but that is not quite the same as doing 
it directly on HF). Tom Rickert, N7CPA, has been indispensable in 
providing much of the information which appears here. 


12.A EQUIPMENT 


Equipment, of course, is one of those subjects of endless ham 
conversation. This section will avoid specific brand-name 
recommendations and try to provide some general guidelines. 


12.A.1 Radios: A radio is a radio, isn't it? Well, yes and no. There are 
some general characteristics which make some radios more suitable than 
others for packet use. Lets consider some of these. 


Stability is very important. Very few older non-synthesized radios are 
adequate in this department. 


Smooth tuning is important. 10 hertz or finer tuning step size makes 
things easier. 


An auxiliary jack on the rear of the radio is handy. But a caution is in 
order. Many newer radios permit packet access though the auxiliary 
jack while the microphone attached to the front of the radio. This 
permits simple up/down tuning at the operator's fingertips with control 
buttons in the microphone. But, with many of these transmitters, when 
the transmitter is keyed, the transmitter accepts (and transmits) all input 
signals. Thus, the transmitter can transmit both packet tones and 
microphone audio at the same time. As a result, if you are not careful, a 
connected microphone can transmit room sound along with you packet 


tones! 


12.A.2 TNCs: Are there special TNC requirements for HF operation? 
Yes! And No! If you are going to operate on 10 meters only, operation 
with VHF settings is permitted (that is, 1200 baud rf data rate). In this 
range of frequencies, you can use your VHF TNC. 


For operation on frequencies lower than the 10 meter band, you need a 
TNC which provides 300 baud and the standard tones used for HF 
operation. This need not be a multi-mode controller unless you also 
wish to operate RTTY, AMTOR, etc. There are a number of TNCs 
which provide this capability. Appendix 2 (in Volume 2) provides some 
detailed information. 


One TNC feature which simplifies HF operation is a tuning indicator. 
While this feature is certainly not necessary, it does remove a lot of the 
frustration, especially when you are beginning. 


12.A.3 Terminals: There is no reason for there to be any difference 
between the terminal you use on VHF and on HF. There are, however, 
terminal programs which simplify the change between VHF and HF. See 
Appendix 1 (in Volume 2) for some suggestions in this regard. 


12.A.4 Antennas: Section 3.E discussed antennas on VHF. In 
general, the same can be said on HF. 


Directional antennas provide gain and reduced noise but cause some 

stations to be hidden from you. Non-directional antennas require no 
rotating and are good in any direction but sometimes provide weaker 
signals. 


12.A.5 Station Layout: Section 4.L discussed station layout. Several 
points deserve emphasis here. 


Computers and TNCs create spurious radio signals. These signals tend 
to get stronger as you get closer to the actual operating frequencies (of 
the computer and TNC). Thus, you can expect some of these to be 
bothersome on HF. Careful grounding of equipment may help 
significantly in this regard. 


Transmitter output powers tend to be higher on HF than VHF. 100W or 
more is not uncommon. This may, in some situations, make a 
computers and TNCs more susceptible to interference from your 


transmitter. Experience has shown that use of an elevated beam antenna 
usually produces fewer problems. But antennas with sections which are 
near ground level (such as "slopers") are quite capable of delivering 
interfering signals to video displays, computers, and TNCs. 


12.B TNC SETTINGS 


RF baud rate was just mentioned as a TNC difference between HF and 
VHF. There are also several parameters which are set usually differently 
on HF than they are on VHF. 


PACLEN is usually set much lower on HF. Values of 30 are often 
recommended but common practice and experience suggests that values 
near 60 are quite adequate. With a packet header of 25 or so characters 
which are not counted as part of the packet length, the efficiency of a 
packet containing only 30 information characters is quite low. 


RETRY values are usually increased on HF. A full 15 retries may not be 
enough! For TNC2s, RETRY 0 causes the TNC to take as many retries 
as necessary and many users take this route. While the impact on a 
busy frequency is not very desirable, it is up to you to determine 
whether or not this is justified in your case. 


12.C FREQUENCIES 


Packet on HF in the United States is limited to frequencies denoted as 
DIGITAL by the Federal Communications Commission. The general 
practice has been that on each band, the RTTY-like signals (RTTY, 
AMTOR, etc) occupy the lower half of each digital sub-band and the 
packet-like signals occupy the upper half. 


Not all nations recognize the same frequency conventions. Even if there 
is a packet signal somewhere else (where you are licensed to operate), 
you may not have the right to operate packet there. 


12.C.1 1200 Baud: operation is permitted only on 10 meters. The 
frequency range in which the FCC permits operation is 28.190 MHz to 
28.205 MHz. 


12.C.2 300 Baud: operation is permitted on each of the HF bands 
from 10 meters down to 160 meters (including the newer WARC 
bands). 


12.C.3 H.F Packet Band Plan: The following is the packet band plan 
recommended by American Radio Relay League. Along with the 
frequencies are noted some of the common usages. 


10 METERS 28.101 300BD 
28.103 300BD 
28.105 300BD 
28.107 300BD BBS FORWARDING 
28.109 300BD BBS FORWARDING 
28.111 300BD BBS FORWARDING 
28.190 1200BD BBS FORWARDING 
28.195 1200BD 
28.200 1200BD 


12 METERS: NO ESTABLISHED BAND PLAN 


15 METERS: 21.100 & below; BBS FORWARDING 
21.101 300BD 
21.103 300BD 
21.105 300BD 
21.108 300BD 


17 METERS: 18.101 300BD 
18.103 300BD 
18.105 300BD 
18.107 CLOVER OR PACTOR 
18.109 CLOVER OR PACTOR 


20 METERS: 14.000 & below , FORWARDING; AMTOR,RTTY,PACTOR 
KYBRD 
14.101 300BD 
14.103 300BD 
14.105 300BD 
14.107 300BD FORWARDING (SOME KBRD) 
14.109 300BD FORWARDING ONLY 
14.111 300BD FORWARDING ONLY 
14.113 300BD FORWARDING 


30 METERS: 10.141 300BD 
10.143 300BD 
10.145 300BD 
10.147 300BD FORWARDING 
10.149 300BD FORWARDING 


40 METERS: 7.100 AND BELOW BBS FORWARDING 
7.101 300BD (SOME FORWARDING ON) 
7.103 300BD (ALL 40 METER FREQ BUT) 
7.105 300BD (BUT GOOD KEYBOARRDING) 
7.108 300BD 


80 METERS: 3.610 TO 3.616 300BD 
160 METRS: NO BAND PLAN 


12.D OPERATING PRACTICES 


Single Side-Band (SSB) is used on all HF bands. The lower sideband is 
used even though voice communication may use different side-bands on 
different frequencies. 


Propagation changes for packet the same way it does for other modes. 
Do not be surprised at the sudden loss of a link. 


On HF, there are many transmitters which are hidden from you. The 
may be hidden by virtue of your antenna directivity. They may also be 
hidden because of propagation. In other words, your conversation with a 
station in Europe may be interfered with (not intentionally of course) by 
stations in Africa or Asia which you simply cannot hear but which the 
station at the other end can. 


While tuning indicators can be very helpful as can frequency lists, the 
proper tuning criterion in the end is best copy. The TNC tuning indicator 
should get you close; usually you can trust it. But some-times, you may 
find that tuning up or down a very small amount may reduce retries and 
the best on-screen copy. 


You may occasionally find signals which sound like very good packet 
signals and produce very good S-meter readings. A tuning indicator may, 
however, show erratic response or no response at all. This is thought to 
be the result of multi-path in which the signal arrives after following two 
different routes. These routes may be around the earth in opposite 
directions. They may take a different number of bounces between the 
earth and the ionosphere. But in either case,the result is the same; there 
are two signals which interfere with each other. Sometimes a directional 
antenna may help sort out the signals. 


Do not use RIT or filter shifts which are available in some transceivers. 


On HF, CQ is sent by placing the TNC into converse mode, then just 
type CQ CQ DE yourcall. This will be sent as a UI frame and 
anybody monitoring will see it. If you also have UNPROTO CoQ set, the 
UI frame will be addressed to the callsign CQ. 


12.E KANODES ON HF 


KaNodes and digipeaters are quite frequently used on HF. You might 
review their operation in earlier chapters (sections 3.C and 10.A). Some 
additional notes are pertinent here. 


12.E.1 Beacons: KaNodes have a fairly distinctive beacon. 


N7CPA>ID 
N7CPA/R NBG/D N7CPA-1/B N7CPA-3/G N7CPA-7/N 


N7KMM>ID 
N7KMM/R JOE/D N7KMM-1/B N7KMM-3/G SPRING/N 


The format for these beacons is as follows: the identifier followed by /N 
is the node name. It can be either an alias or a callsign. This is what you 
connect to for connection services. 


The identifier followed by /B is the BBS (mailbox). This is what you 
connect to to leave or get mail. SSID of 1 is commonly used. 


The identifier followed by /D is the digipeater. This is what you use to 
digipeat. In general, other SSIDs of this call will not digipeat! 


The identifier followed by /R is the basic identification of the node. This 
is usually the callsign without any SSID. 


The identifier followed by /G is the gateway. Using this callsign permits 
one to digipeat from one side of the KaNode to the other. For example, 
suppose that you are on HF and happen to be on the same frequency as 
W9AA-3/G. Also, suppose that N9ZZ is accessible on the VHF side of 
the W9AA KaNode. You can use the following connect command: C 
N9ZZ vy W9AA-3 . W3AA-3 will hear this connect request and serve as 
a digipeater, digipeating from (in this case) the HF side to the VHF side. 
If the VHF path is good, N9ZZ will hear this digipeated connect request 
and respond. The same process works from the VHF side to the HF 
side. 


12.E.2 Node Connects vs Digipeating: The comments concerning 
node connection vs digipeating in sections 3.C and 3.D apply equally in 
HF. There are though, as one might expect, some special 
considerations. 


Digipeating is undeniably faster when it comes to establishing a link. 


You simply type out the connect string with all the digipeaters and, if it 
all works, back comes the acknowledgement. When you use node 
connection services, you get back the logon message from each one, 
then tell it the next connection, and so on. So, if speed of setting up the 
link is a major issue, digipeating will win out. 


But if you expect to carry on an extended conversation, using node 
connection services is superior. The number of packets cluttering the 
frequency are reduced because retries are handled between the two 
points where the failure actually occurred. Using digis requires each 
error correcting retry to be resent from one end all the way to the other. 
Using the connection services of KaNodes does not add the networking 
overhead characters used by Net/Rom nodes so the penalty is very 
small. On top of this, the stay-connected feature of a KaNode can really 
help; this is discussed in the next section. 


12.E.3 Stay Connected: KaNodes have a very interesting feature 
known as stay-connected. If you ask a KaNode to connect you to 
something else (either on the same frequency or on the cross-frequency) 
and the link fails, that resulting disconnect ripples back to the KaNode 
and it, in turn sends a disconnect on to you. This is the way a "normal" 
(that is, not stay-connected) connect works. 


But if you tell the KaNode to connect you to something else and to stay 
connected, the disconnect from the far side of the KaNode stops right 
there. The KaNode notifies you with a special message. The following 
example shows the result of a stay-connected connect between the node 
ALBOR (origin) and the node MOORE. The link was setup and 
operated, then failed. 


###DISCONNECTED BY MOORE AT NODE ALBOR 
ENTER COMMAND: B,C,J,N,X, or Help ? 


This message shows that a disconnect (for any reason) happened 
beyond ALBOR. The result rippled back to that point but stopped. 


This connection was established from the VHF side of ALBOR by using 
the command X MOORE S. The X, as discussed earlier is the 
cross-connect command. This is followed by the name or callsign of 
the station being connected to. What is different is the ending S. 

This last character indicates that the connection is to be made as a 
stay-connected type. 


12.F- SUMMARY 


Operation on the HF amateur bands requires some equipment which is 
slightly different than that used on VHF. Radio baud rates are different 
as are tone frequencies. Beyond this difference and the requirement for 
a Stable and easily tuned HF transceiver, the equipment needs differ little 
from VHF. 


Operating frequencies are limited and the propagation has all of the 
vagaries of other HF modes. There are a number of operating strategies 
which are unique on HF. Likewise, the extensive use of KaNodes serves 
to add to the differences between VHF and HF. 
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SATELLITES 


Maybe the idea of using satellites for packet contacts tickles your fancy. 
This chapter will attempt to provide some information to help you decide 
whether you really want to or not. 


The author is even less of a packet satellite expert than he is an expert on 
H.F. He has operated a few times using a digipeater on the MIR space 
station. That can be really exciting but it represents a very small part of 
satellite use. 


13.A WHAT'S UP? 


There are several broad categories of satellites which support packet 
operation. Here, we will look at these groups of satellites. 


13.A.1 Manned Space Stations: The Soviet MIR space station and 
the U.S. Space Shuttle program have both, at various times, included 
packet operation. The usual style seems to have been operation in space 
just like on the surface. Standard AX.25 TNCs with VHF transceivers 
having a few watts output seem to have been the rule. Two meters 
seem to have been the most popular band. MIR has frequently used 
145.55MHz. Since ordinary TNCs are normally used, they seem 
frequently set up so that you may connect to a mailbox or use it as a 
digipeater. 


The inclusion of packet on a particular mission seems to depend on 
whether there are hams among the crew and whether the radio 
equipment is compatible with the rest of the mission. 


On can usually find out about these events by watching BBS bulletin 
lists. In the case of shuttle flights, bulletins often start showing about a 
week before launch. U.S. Space Shuttle flights with ham radio are 
referred to as SAREX (Shuttle Amateur Radio EXperiment) and bulletins 
usually include the word SAREX in the subject. Shuttle flights seem to 
frequently be in low inclination orbits; do not expect access much above 
45° (N or S) latitude. The MIR orbit is at a higher inclination and is 


accessible from above 50° (N or S). 


Using one of these stations is little different than connecting to your 
neighbor at home. One very big difference is the coverage area; virtually 
every other user is hidden to every one else. Also, these events are 
relatively rare and the user load can be huge. 


13.A.2 Geostationary Satellites: Though planned, there are no 
geostationary ham satellites in space at the time this is being written. 


13.A.3 High Orbit Satellites: AMSAT-OSCAR 13 (AO-13) is a 
satellite in a highly elliptical orbit. This orbit is such that it swings well 
away from the earth; it is frequently referred to as Phase III orbit. It is 
visible for an extended period and is relatively slow moving when away 
from the earth. There are does not appear to be any dedicated packet 
operation although packet seems to be permitted as a mix with other 
modes. Because of the rather large satellite-to-earth distances, transmit 
power and receiver noise figure are major issues. There is a baudot 
telemetry beacon; the author assumes this mean RTTY. 


AO-13 has 4 different modes. Each one represents a particular 
input-output frequency combination. For example, mode B is uplink on 
70cm and downlink on 2M; mode J is uplink on 2M and downlink on 
70cm. There are also a pair of modes which translate between 70cm 
and 2.4GHz. The mode schedule is often broadcast 

by BBS bulletins. Remember, however, that this satellite, as for most 
others, uses CW or SSB, not FM! 


A new satellite launched in mid-1993 is ARSENE. This on is also in a 
highly elliptical obit going from 36,000km at the maximum (apogee) to 
20,000km at the minimum (perigee). Orbital period is about 17hours and 
30 minutes. It is expected to have a life of about 3 years. It is not 
obvious to the author whether it has been given has been given an 
OSCAR designation. 


The expected packet 70cm uplink/2M down link is not operating. There 
is, however, a 435.100MHz uplink/2400MHz downlink. Transmit 
requires 500-1000W EIRP (50W into a 10db gain antenna) works. The 
downlink is some 10db weaker than AO-13, however and the antenna 
requirement is equivalent to a 6' dish. 


13.A.4 Microsats: These six satellites were launched in January, 1990. 


The orbits of all four at very similar and all are visible about 15 minutes 
at a time, 4 to 5 times per day (at mid-latitudes). Their altitude is low. 
They are simple. Because of their small size and weight, they can be 
launched at lower cost. The group consists of University of Surrey 
(England) UoSAT-3 (UO-14) and UoSAT-4 (UO-15), AMSAT AO-16, 
OSCAR-17, Weber OSCAR-18 (WO-18), and AMSAT LO-19. Lets 
consider each of these six satellites in numerical order. 


UO-14 has one uplink and one downlink, both at 9600 baud. Uplink and 
downlink are full duplex (on different bands). 


The author has no information about UO-15; it does not appear to 
support any special packet operations. 


AO-16 is also known as PACSAT. AO-16 has 4 uplinks and 1 downlink 
running at 1200 or 4800 baud (switchable). A PACSAT modem is 
required for operation. Uplink is on 145.900, 145.920, 145.940, and 
145.960 MHz while the downlink is on 437.025, 437.050, or 2401.143 
(full-duplex). 


This satellite is basically a flying mailbox. But operation style is very 
different from earth-bound ones. They forward bulletins by 
broadcasting to everyone listening. Every bulletin is sent over and over 
until all of the pieces are received and patched together by everyone 
interested. It may take several passes for one to be received in its 
entirety. The ground station must be able to reassemble the individual 
pieces into a complete message. The satellite continues broadcasting until 
there are no more requests for repeats or the message is too old and 
must be purged. Personal messages are handled on a direct connect 
basis. So is placing a message (personal or bulletin) into the mailbox. 


It usually requires moderate-gain directional antennas with full tracking 

capability. It also requires special software to format messages to meet 
the satellite requirements and to compress the messages (reducing both 
connect time and satellite memory needs). The special software is also 
needed to reassemble broadcast bulletins. When one adds the dual-band 
radio needed, this is not an inexpensive undertaking! 


AO-17 is also known as DOVE (Digital VOice Encoder). Its primary 
mission is to broadcast digitized audio messages on FM for classroom 
use. It has a packet telemetry channel which can be decoded by 
G3ZCZ's WHATS-UP. Telemetry frames are 1200 baud UI frames (in 
pairs) addressed to DOVE-1>TLM. The downlink appears to be on 


145.825MHz. 


WO-18 (WEBERSAT) carries a camera. The images are digitized and 
transmitted on a packet downlink operating on 437.102. A 1200 baud 
PACSAT modem is required for reception. 


LO-19 (LUSAT) is almost identical to AO-16. 


13.A.5 Sun Synchronous Satellites: Fuji-Oscar 20 was launched in 
February, 1990. It is in a sun synchronous orbit which means that it 
crosses a given longitude at approximately the same time, morning and 
evening, every day. The Japanese designation is Fuji-2 and the 
international designation is FO-20 (Fuji-OSCAR 20). The orbital period 
is about 105 minutes and the expected service time is 5 years. 


This satellite is designed for packet operation. It has 4 uplink channels 
(145.85, 145.87, 145.89, 145.91 MHz) and 1 downlink channel (435.91 
MHz). Packet operation requires the same PSK modem as needed for 
PACSAT. Uplink requires about 100W EIRP. The packet callsign is 
8JIJBS. 


There are several interesting features for packeteers on this satellite. 
One is the digipeater. It will digipeat any valid packet heard; you do not 
have to specify the satellite as a "via" in the connect request. The 
digipeat is cross-band (that is, the outgoing packet is on the downlink). 
Another interesting feature is the bulletin board; it carries a large 
computer memory for message storage. The BBS is accessible with 
common mailbox-style commands. 


The downlink contains telemetry frames which are broadcast as UI 
packets. They are addressed 8JIJBS>BEACON. If you have a 
PACSAT modem, you can copy and translate the telemetry with 
G3ZCZ's WHATS-UP program (see Chapter 19 in Volume 2). 


There is a caution about FO-20. It does not automatically disconnect 
you when the signal is lost. This means that when it goes over the 
horizon, it considers that you are still connected. The problem is that it 
permits only 16 simultaneous connects. If it goes over the horizon with 
you still connected, your lost connection stays on as | of the 16. So, 
please disconnect before signal is lost! 


13.A.6 Other Satellites: KITSAT-1, also known as KO-23 was 
launched early in 1993. This satellite is a Korean effort including 9600 
baud packet, earth imaging, cosmic ray experiments, and digital signal 
processing experiments. 


Unlike other packet satellites, this one uses FM on both the up and down 
links. There are two uplink frequencies (145.850 and 145.900MHz) and 
a downlink on 435.175MHz. Transmit requires 25-100W EIRP and 
receive needs a GaAsFET preamp and a small beam. PSK is used as 
with the PACSATS but at 9600 baud. The packet callsign appears to be 
HLO1-11 (thats zero-one dash eleven). It uses the broadcast protocol 
very similar to FO-20. 


UoSAT-OSCAR 22 (UO-22) is also a packet satellite. It operates at 
9600 baud. Beyond this detail, the author has little information. 


OSCAR-21 (AO-21) has packet telemetry and voice. It has a downlink 
on 145.987MHz FM (145.990 works fine) and an uplink on 435.016MHz 
FM. It is in a fairly low orbit and has viewing times in the neighborhood 
of 15-20 minutes. 


13.B FINDING SATELLITES 


After questions of equipment and frequencies, the next most often asked 
question often seems to be "how can I tell when a satellite is coming 
over?" You can use one of several tracking programs for computers or 
you can do some simple estimating. But in either case, you need to start 
with some basic information about the orbit of the satellite. The 
standard set of information is called the Keplerian Elements. 


13.B.1 Getting Keplerian Elements: Keplerain Elements are available 
on a regular basis from several sources. A number of telephone bulletin 
boards around the U.S. have them available in a timely manner. They are 
also available in Internet. They are also distributed through the radio 
BBS system in many areas. 


13.B.2 Keplerian Element Formats: Once you have a recent set of 
the elements, the next issue is what they mean. Here, we have a minor 
problem. They have been issued in two formats, AMSAT and NASA. 
In 1991, AMSAT format was generally dropped in favor of the NASA 
format. But many of the older tracking programs expect data files in 


AMSAT form. The following conversion information was apparently 
written by Dr T.S. Kelso, Assistant Professor of Space Operations, Air 
Force Institute of Technology and was taken from an Internet message 
dated August 31, 1990. 


Data for each satellite consists of three lines in the following format: 


AAAAAAAAAAA 
1 NNNNNU NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N +NNNNN-N N NNNNN 
2 NNNNN NNN.NNNN NNN.NNNN NNNNNNN NNN.NNNN NNN.NNNN NN.NNNNNNNNNNNNNN 


Line | is a eleven-character name. 


Lines 2 and 3 are the standard Two-Line Orbital Element Set Format 
identical to that used by NASA and NORAD. The format description is: 


Line 2 

Column Description 

01-01 Line Number of Element Data 

03-07 Satellite Number 

10-11 International Designator (Last two digits of launch year) 

12-14 International Designator (Launch number of the year) 

15-17 International Designator (Piece of launch) 

19-20 Epoch Year (Last two digits of year) 

21=32 Epoch (Julian Day and fractional portion of the day) 

34-43 First Time Derivative of the Mean Motion 
or Ballistic Coefficient (Depending on ephemeris type) 

45-52 Second Time Derivative of Mean Motion (decimal point] 
assumed; blank if N/A) 

54-61 BSTAR drag term if GP4 general perturbation theory was 
used. Otherwise, radiation pressure coefficient. 
(Decimal point assumed) 

63-63 Ephemeris type 

65-68 Element number 

69-69 Check Sum (Modulo 10) 
(Letters, blanks, periods = 0; minus sign = 1; plus sign 

=2) 

Line 3 

Column Description 

01-01 Line Number of Element Data 

03-07 Satellite Number 

09-16 Inclination [Degrees] 

18-25 Right Ascension of the Ascending Node [Degrees] 

27-33 Eccentricity (decimal point assumed) 

35-42 Argument of Perigee [Degrees] 

44-51 Mean Anomaly [Degrees] 

53-63 Mean Motion [Revs per day] 

64-68 Revolution number at epoch [Revs] 


69-69 Check Sum (Modulo 10) 


All other columns are blank or fixed. 


Example: 


NOAA 6 
1 11416U 86 50.28438588 0.00000140 67960-4 0 5293 
2.11416 98.5105 69.3305 0012788 63.2828 296.9658 14.24899292346978 


Note that the International Designator fields are usually blank, as issued 
in the NASA Prediction Bulletins. 


Additional conversion information was provided by Mike Bilow, 
NIBEE@ KAIRCILRI.USA.NA in a BBS bulletin dated February 16, 
1992. 


Note that some software will not correctly read all of the (NASA) 
fields, often stumbling over the assumed decimal point in the 
eccentricity field. 


Also, decay rate or drag is usually given in AMSAT format in 
scientific notation, which is not used in NASA format. To convert, 
simply move the decimal point to the left as many places as are 
indicated in the negative exponent. For example, 1.234e-05 becomes 
0.00001234, and 6.789e-03 becomes 0.006789; most software will take 
this number entered either way. 


All epochs are UTC (Coordinated Universal Time). 


Example: 


STS-35 
1 20980U 90106 A 90340.71451300 .00053642 00000-0 37954-3 0 129 
2 20980 28.4668 332.8436 0011228 341.6274 18.4530 15.72433683 705 


AMSAT Format: 
Satellite: STS-35 
Catalog number: 20980 


Epoch time: 90340.71451300 
Element set: 12 

Inclination: 28.4668 deg 

RA of node: 332.8436 deg 
Eccentricity: 0.0011228 

Arg of perigee: 341.6274 deg 

Mean anomaly: 18.4530 deg 

Mean motion: 15.72433683 rev/day 
Decay rate: 5.3642e-04 rev/day*2 
Epoch rev: 70 


13.B.3 Using Keplerian Elements: It is possible to make some fairly 
simple estimates of satellite passes without extraordinary mathematical 
gymnastics. All that it requires is some simplifying assumptions. The 


assumptions I have made are: (1) the orbit is circular (which leaves out 
the Phase III satellites) and (2) many of the more subtle orbital 
mechanics issues can be ignored for a while after the epoch time. 


The method I have chosen is to determine where a crossing of the 
equator must happen in order that a pass be visible. Then, an estimate of 
equator crossing times and locations is made. By cross-checking these 
values, you can determine pass times. You will need to know your 
latitude and longitude to about | degree or so. This method will not 
provide any antenna pointing information. 


Step A: Based on orbit altitude, determine how large an area over which 
the satellite can be seen. The radius of the circle (on the earth's surface) 
in which a satellite is visible is given by 


= R*k* We, R 
r=R*k atn| 1428 


where R is the radius of the earth (6378km) and h is the orbital altitude 
of the satellite (in the same units as R). The factor k is used according 
to whether your calculator gives angles in degrees or radians from the 
atn (arctangent) function. If your calculator gives the answer 45 to the 
function atn(1), then use k=pi/180 (to convert degrees into radians). But 
if your calculator gives the answer 0.785, use k=1 since the answer is 
already in radians. 


There is, however, a minor hitch. Orbital altitude is not given in the 
Keplerian Elements. Orbital period is. And altitude is directly related to 
period by 


where T is the orbital period, M is the mass of the earth, and G is the 
Universal Gravitational Constant, and r is the radius of the satellite's 
(circular) orbit.. When we are interested in a satellite orbiting the earth, 
this equation reduces to 


273 
r= 331.25* T 


if T is in minutes and r is in kilometers. The orbital altitude of the 
satellite is 
h=r—-R 


273 
h= 331.25*T — 6378 


The Figure 13-1 gives radius of satellite viewing circle and the orbital 
radius (both in km) as determined by orbital period. 
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Figure 13-1, View-Circle Radius and Orbit Radius for various Orbit Periods 


The final consideration is that the Keplerian Elements do not give orbital 
period directly. Instead, it gives "mean motion" which is the number of 
orbital revolutions in one day. To find the orbital period, simply divide 
this value into 24*60=1440, the number of minutes per day. In the 
example from section 13.B.2, the orbital period is therefore 91.578 
minutes or 91 minutes, 34.68 seconds. 


Step B: The second step is to determine how many degrees of latitude 
and longitude the radius of the viewing circle occupies at your site. 
Lines of longitude go from pole to pole and all have the same 
circumference; lines of latitude are parallel to the equator and ones nearer 
the poles have a smaller circumference. Both longitude and latitude are 
divided into 360 degrees. What may be confusing to some, however, is 
the actual measurement of latitude and longitude. Longitude (in degrees) 
is a measure of how many lines of longitude one has crossed east or 
west of Greenwich Meridian (that is, while travelling along a line of 
latitude!) Similarly, latitude (in degrees) is a measure of how many lines 
of latitude one has crossed north or south of the equator (that is, while 
travelling along a line of longitude!) 


To find the east-west radius, slice the earth at your latitude (circles 


parallel to the equator). The resulting circle has a circumference which 
is determined by the radius of the earth and the latitude where the slice 
takes place. From this, we can determine the distance occupied by one 
degree of longitude; there are 360 degrees of longitude around this circle 
which has a radius of R*COS(LAT). Combining this value with the 
radius of the viewing circle from Step A results in an estimate of the 
east-west width of the viewing circle in degrees. The north-south radius 
is the same everywhere on the earth and is found much the same way, 
except the slice is along a line of longitude. 


The number of km in one degree of longitude (lets call it Q] ON) at a 
latitude of LAT is given by 


Q oy = 272" R*COS LAT)/360 


where R is the radius of the earth. If we combine the constants in this 
equation, the result is 


Qs oy = 11 2km™ COS LAT) 
The number of km in one degree of latitude (lets call it QLAT) is simply 
112.2km. 


The next figure, Figure 13-2, shows the value of QLON (number of 
kilometers in | degree of longitude) for degrees of longitude from 0 
(equator) to 50. It makes no difference, here, whether you are north or 
south of the equator. 
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Figure 13-2 QLON Vs Latitude 


The last part of this step, which is not convenient to graph, is to divide 
radius of the viewing circle by Q] ON. This gives the east-west radius 
of the viewing circle, in degrees of longitude. Similarly, divide the radius 
of the viewing circle by Q]_ AT to find the north-south radius of the 
viewing circle in degrees of latitude. 


For example, if the satellite in question has an orbital period of 91.578 
minutes (in other words, the example satellite), the radius of its viewing 
circle is about 2200km. If you are at 40 degrees south latitude, your 
value of QL.ON is about 78 km/degree. Thus, the east-west radius of 


the viewing circle occupies about 28 degrees of longitude; the east-west 
diameter is twice this, or about 56 degrees of longitude. The 
north-south radius is about 20 degrees of latitude. 


Step C: The next step is to estimate when the satellite crosses the 
equator. This estimate involves several quantities from the Keplerian 
Elements. 


The first part of this step is to understand what Epoch time means. 
Epoch time is a decimal time and date value. The example in section 
13.B.2 shows an Epoch time of 90340.71451300. The first 3 digits to 
the left of the decimal point are the Julian day. January 1 is day 001, 
February 1 is day 032, December 31 is day 365 (or 366 if a leap year). 
In this example, the day is 340. The next digits to the left of the day 
number are the least two digits of the year. In the example, these digits 


are 90 so the day is day 340 of 1990. The digits to the right of the 
decimal point give time as a decimal part of one day, that is 24 hours. 
Though it is not necessary for our purposes to convert to hours, 
minutes, and seconds, we can readily do so. Hours are found by 
multiplying 24 hours by the decimal part of Epoch time. In the example, 
the hour part is 24*0.71451300 or 17.148; hours are the integer part, or 
17. The portion to the right of this number is decimal part of hours. 
Multiplying this fraction by 60 (minutes per hour) gives minutes. In the 
example, the minute part is thus 60*0.148 or 8.88. Minutes could be 
rounded to 9 or further reduced to seconds. Seconds are obtained by 
multiplying the fractional part by 60 (seconds per minute). In the 
example, the seconds part is thus 60*0.88 or 53. Thus, the complete 
time represented by the Epoch time in the example is 17:08:53 on day 
340 of 1990. It is the convention that Epoch time is given in GMT. 


The satellite makes each subsequent north-bound crossing of the equator 
one orbital period time after the preceding crossing. Furthermore, each 
south-bound crossing of the equator happens one-half of an orbital 
period after the north-bound crossing. For the satellite in the example, 
the next north-bound equator crossing is at 91.578 minutes after the 
Epoch time (17:08:53 GMT) or 18:40:27 GMT. Note that while any 
individual time need be accurate only to a few seconds, you should 
maintain several digits to the right of the seconds decimal point since 
errors will accumulate fairly rapidly. The next north-bound crossing will 
be at 20:22:02 GMT. 


Step D: Knowing when the satellite crosses the equator must be 
combined with where the satellite crosses the equator. This involves the 
RA of node data from the Keplerian Elements. 


The RA of node has nothing to do with packet nodes. It gives the 
location, called Right Ascension (in degrees longitude) where the satellite 
crosses the equator north-bound at the specified Epoch time. An oddity 
of this value is that given in a range of 0 to 359.9999 degrees positive 
eastward of Greenwich Meridian. In the example, the RA of the 
example is 332.8436 degrees. Any value between 0 and 180 may be 
taken directly as East Longitude. Values greater than 180 may be 
converted to West Longitude by subtracting from 360. The example 
thus crosses the equator at 27.156 degrees West Longitude. And it 
makes this crossing at the Epoch Time which was analyzed in the 
preceding step. 


But what about the subsequent equatorial crossings? Here, it gets a bit 
complex and several simplifications will be used. There are two 
components which interact to determine equatorial crossings. One is the 
rotation of the earth and other is the rotation of the plane of the satellite's 
orbit in space. It is quite possible to get wrapped up in distinctions 
between Siderial time and Sun time but for intervals of a few days or 
less, the error from using Sun time (that is, clock time), is reasonably 
small. Using this simplification, we will find the number of degrees 
which the earth rotates during one orbital period. The earth rotates 360 
degrees in 24 hours clock time or 15 degrees per hour. It may be 
simpler to use degrees per minute since orbital period is usually 
expressed in minutes. Earth rotation in degrees per minute is the degrees 
per hour value divided by 60 minutes per hour. Thus, earth rotation is 
also 0.25 degrees per minute. In our example which has an orbital 
period of 91.578 minutes, the earth rotates 22.895 degrees during each 
orbit and 11.449 degrees between every equator crossing. 


That, however, is not the whole picture. We need to make certain we 
understand which way the earth rotates. You can visualize what 
happens by looking at a globe which turns. If you start looking when the 
Greenwich Meridian is directly below, the numbers along the equator 
increase in a westerly direction. When you reach the area of 
International Date Line, the numbers switch to East Longitude and 
decrease from 180 toward 0. The convention in earth satellite orbital 
mechanics is eastward positive; thus, the earth's rotation is -0.25 
degrees per minute. Then, for our example, the earth rotates -22.895 
degrees during each orbit. 


One last factor must be considered before the whole series of equatorial 
crossings can be estimated. This factor is the rotation of the plane of 
the satellite's orbit in space. If we were to sit in space directly above 
one of the earth's poles, further out in space than the orbit of the satellite 
and ignore the rotation of the earth, we would also see that the plane of 
the satellite's orbit slowly rotates below us. This orbital-plane rotation is 
called precession and is controlled by the inclination of the orbit. 
Precession is an effect which is due to the fact that the earth is not a 
perfect sphere; it bulges at the equator. Inclination is the angle between 
the equator and the plane of the orbit. The rate of orbital-plane rotation 
for an earth satellite is given by 


3.5 
dasat=9.95 2)  costi) 


This is an empirical equation. The quantity dQ/dt is in degrees per day. 
A positive value indicates clockwise rotation of the orbital plane as seen 
from above the north pole. In our example, the inclination angle, 1, is 
28.4668 deg. Given the values of R (earth's radius = 6378km) and r 
(satellite's orbital radius = 7300km from the figure in Step A), the 
precession rate is 5.2 degrees per day. Note that a true polar orbit, in 
which i=90 degrees, (that is, the satellite crosses the equator heading 
exactly due north) has a precession rate of zero. Also, a satellite with a 
an inclination greater than 90 degrees has a negative precession and the 
orbital plane rotates counter-clockwise as seen from above the north 
pole. An inclination of 45 degrees means that the satellite heads 
northeast as it crosses the equator north-bound; an inclination of 135 
degrees means that the satellite heads northwest as it crosses the equator 
north-bound. 


We really need to know the rotation of the orbital plane during one orbit. 
Lets call the change in the angle of the orbital plane during one orbit, AQ. 
If T is the orbital period, in minutes, then 


AO ew GA~ 1 Lee dQ. _T 
dt 24 60 dt 1440 


Is the rotation of the orbital plane added to or subtracted from the earth's 
rotation? If the two are rotating in opposite directions, then the change 
between successive right ascensions is even greater. Thus, since earth 
rotation counter-clockwise as seen from above the North Pole, AQ is 
subtracted from earth's rotation. For our example satellite, AQ is 0.331 
degrees per orbit and the total change in RA is -22.895-.331=-23.226 
degrees (that is, 23.226 degrees westward). This change is called the 
orbital increment. 


The next RA after the Epoch Time thus happens at the RA given in the 
Keplerian Elements shifted west 23.226 degrees or 
27.1564+23.226=50.382 degrees. Each subsequent RA is another 23.226 
degrees west of the preceding one. 


Step E: The final step shows which orbits are visible and when they 
occur. Make 2 copies of the Figure 13-3, the ORBITRACK chart, on 
page 13-16. 


On one copy, locate the site of your station. If you are in the southern 
hemisphere, swap east and west on the equator. Mark out the east-west 
and north-south extents of the circle of visibility centered at your site. 


Connect these four points with a smooth line which might be somewhat 
egg-shaped. This line is the edge of the circle of visibility. A satellite 
crossing anywhere within this circle is visible from your site. With a 
sharp knife, cut along the visibility circle to make a hole. Note the 
arrowhead mark on the 0° longitude (Greenwich Meridian). Then, trim 
off the outer part of this copy along the circle where the arrowhead 
points (equator). 


On the other copy, mark the orbit. For convenience, start with a mark 
at Greenwich Meridian (0 on the equator). If the orbital inclination is 
less than 90 degrees, find the point along the 90°E longitude line at a 
latitude equal to the inclination angle. If the inclination is greater than 90 
degrees, find the point along the 90°W longitude line equal to 
(180-inclination). For our example satellite with an inclination of 
28.4668 deg, mark on the 90°E longitude line about 28.5 degrees north 
of the equator (not very far north!). If the inclination had been 110 
degrees, the mark would have been on the 90°W longitude line 70° north 
of the equator. Make a third mark on the equator near the 180° point. If 
the orbital increment is negative, place this mark clockwise of the 180° 
line a distance of one-half the orbital increment. If the orbital increment 
iS positive, place the mark counter-clockwise of the 180° line a distance 
of one-half the orbital increment. For the example satellite which has an 
orbital increment of -23.226 degrees, make this mark about 12 degrees 
CW of the 180 mark (or 168°E). Make a smooth arc connecting these 
three points. Cross each latitude line only once between 0° long and 90° 
long and only once between 90° long and 180° long. Color the half 
between Greenwich Meridian and the 90° longitude line green and the 
other half red. Green indicates moving away from the equator and red, 
toward the equator. Extend these red and green lines out to the 
outer-most circle (which has no longitude lines). 


Now, place a pin though the center mark of the first copy. Put this 
copy over the second copy (the one with the orbit marked) and pin them 
together so that they rotate relative to each other. Notice that as they are 
turned, there are positions where the orbit shows through the 
viewing-circle hole and other positions where the orbit is hidden. There 
may be two discontinuous settings of the top disk where the orbit is 
visible; this is usually the case only with orbits which have inclinations 
near 90° and when this happens, the point where the orbit changes from 
green to red cannot be seen inside the hole. 


Rotate the two disks until the green orbit line just becomes visible in the 
hole. Make a green mark on the edge of the upper disk opposite the 0° 


mark of the lower disk. Continue to rotate the disk. If the point where 
the orbit changes from green to red shows in the hole, continue to turn 
the disks until about equal lengths of red and green line show. Place a 
mark (red or green) on the edge of the upper disk opposite the 0° mark 
of the lower disk. If the green line disappears from the hole, place a 
green mark on the upper disk opposite the 0° mark of the lower disk at 
the point where the orbit just disappears. Do the same with red marks 
where the red portion of the orbit just appears and disappears. Color the 
top disk green between the green marks and red between the red marks. 


Next, align the arrowhead mark of the upper disk with the 0° longitude 
line on the lower disk Write down the range of longitudes where the 
green coloring is and where the red coloring is (using the longitude scale 
along the equator of the lower disk since it was cut off of the top disk). 


An RA anywhere within these longitude values produces a satellite pass 
which is visible from your site. If the RA is one in the green range, you 
will see the satellite moving from the equator toward the pole; if the RA 
is in the red range, it is moving from the pole toward the equator. You 
need only to use the orbital increment to estimate the sequence of RAs 
after the Epoch Time. Use the orbital period to determine when the RAs 
happen. Any RA which falls within either the green range or the red 
range should interest you. 
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FIGURE 13-3, ORBITRACK CHART 


A Worked-out Example: The author's location is about 122°W and 
45° N. From Step B, QL. ON is about 80km per degree and Q] AT isa 
111.2km per degree. Since the viewing circle for the example satellite 
has a radius of 2200km, the east-west extent of the viewing circle is 
27.5 degrees and the north-south extent is 19.8 degrees. Thus, the 
viewing circle at the author's location extends from [64.8°N, 122°W] to 
[45°N, 94.5°W] to [25.2N, 122°W] to [45°N, 149.5°W]. The oval 
which links these four points is cut out of the first copy as described. 
The second copy is marked with the orbit exactly as outlined in Step E. 


The first thing which might be discovered is that the orbit barely shows 
above the lower edge of the viewing circle. This should tell us that the 
satellite, when it is visible, will always be low on the southern horizon. 
In fact, the orbit is so low that it is quite difficult to discern precisely 
when it is visible. 


Rotate the two disks as described; mark the upper disk (opposite the 0° 
line of the lower disk) when the green orbit first appears in the viewing 
circle. Turn the upper disk further until equal amounts of green and red 
orbit show in the circle; put both a red and a green mark on the upper 
disk opposite the 0° line of the lower disk. Finally, continue turning 
until the red orbit just disappears from the circle and mark the upper disk 
with a red mark (again, opposite the 0° line of the lower disk). Now 
color with a red marker on the upper disk between the two red marks 
and with a green marker between the two green marks. To determine 
the corresponding RAs, rotate the upper disk until the arrowhead on the 
upper disk which denotes its 0° longitude lines up with the 0° latitude on 
the lower disk. We can now read off the range of RAs which result in 
visible satellite passes. It should come out green between 170°E and 
148°E and red between 148°E and 120°E. Any RA in this range will 
result in a visible satellite. The following brief table shows a number of 
RAs after the Epoch Time. These are also marked with orbit number. 
Note from the original Keplerian Elements that the orbit for the given 
Epoch Time is orbit 70. 


Orbit number RA Time, GMT 
70 27.156°W 17:08:53 
71 50.382°W 18:40:28 
72 73.608°W 20:12:03 
73 96.834°W 21:43:38 
74 120.060°W 23:15:13 
75 143.286°W 00:46:48 
76 166.612°W 02:18:23 
77: 170.262°E 03:49:58 
78 147.036°E 05:21:33 


Orbit 77 might be visible for a very short time. Orbit 78 falls near the 
middle of the visible range. Note that the times shown are equatorial 
crossing. The satellite will become visible, when it does, a short time 
after the time shown. 


Note, particularly, how the RA value is handled after the crossing of the 
International Date Line at 180°. 


13.C MORE INFORMATION 


This chapter has been very sketchy. There are several books which can 
provide more information. These are listed in the Bibliography (Volume 
2). Your national amateur satellite organization can also provide a lot of 
information. In the United States, contact AMSAT-NA at 850 Sligo Ave, 
Silver Spring, MD, 20910-4704. Include a self-addressed and stamped 
envelope when requesting information. 


Software and Keplerian Elements are available on a number of telephone 
bulletin boards. These include the AMSAT BBS (201) 261-2780, the 
SPACELINK BBS (205) 895-0028, the Dallas Remote Imaging BBS 
(214) 394-7438, and CompuServe. 
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TRANSFER 


File transfer concerns the exchange of computer "files" with other 
packet stations. 


14.A TEXT FILE TRANSFER 


A text file is one which contains ASCII characters representing text. 
Only a few specific control characters are included. These are usually 
such things as carriage returns. 


Virtually every computer includes this basic file type. On MS-DOS 
machines, when you doa TYPE filename.ext and get out a screen 
listing as it was typed, it is a text file. C64, Macintosh, and all others of 
which the author is aware have similar file types. This does not mean 
that they can be read by exchanging disks. But they can be exchanged 
by packet. This is because, to the computer, the packet input and output 
is as if it were typed on that machine. 


14.A.1 SENDING TEXT FILES: Almost every terminal program has a 
"SEND TEXT" option. It may masquerade by different names. 
Sometimes it appears as "UPLOAD". In general, you simply specify the 
file name (including extensions for non-Macintosh users). 


The computer then sends the text out the serial port to your TNC as if 
you were typing it. Depending on the program, it may not always end 
by itself. You may need to specify when the end has occurred. 


The only "trick" is that the station at the other end usually must be 
prepared before the sending starts. See the next section. 


14.B.2 RECEIVING TEXT FILES: Almost every terminal program has 
a "RECEIVE TEXT" option. It may masquerade by different names. 
Sometimes it appears as "DOWNLOAD" or "CAPTURE". In general, 
you simply specify the file name (including extensions for 
non-Macintosh users). 


In general, you must initiate CAPTURE prior to the arrival of the first 
text. Computers which support mouse text selection (such as 
Macintosh or Windows) may permit you to choose the text on the 
computer screen after it has been received, then copy it, and paste it into 
another program (such as a text editor). It can then be edited, if 
appropriate, then saved. 


14.A.3 WHY USE TEXT FILES?: Your BBS messages will look a lot 
better if you prepare them before-hand with a text editor. Then, when it 
is all "spiffed up", you can send it. It goes a lot faster, also, than when 
you type it directly. 


14.A.4 CREATING TEXT FILES: Most editors ("word processors, by 
another name) will produce text files. Simply type the message and save 
itas a "plain text" file. For example, "BRIEF" (a text editor widely used 
by programmers) inherently produces plain text. "Word Perfect" allows 
you to save and input text files using the "TEXT IN/OUT" (control-F5). 
Microsoft "Word For Windows" does it if you use a file extension of 
.TXT. "PC-Write", one of the popular share-ware editors, does it 
directly. It appears that many of the Macintosh editors give you the 
"text" option from the "Save As..." item in the File Menu. 


How do you tell if it is a plain text file? The easiest way on a "DOS" 
machine is to "TYPE" the file (from DOS, TYPE filename.ext ). If it 
appears on the screen without strange characters (happy-faces and 
such), then you have done it. 


Please, do not rely on line-wrap by the editor. Many editors in text mode 
leave out carriage returns at the wrap points. If the person receiving 
such a file has one of the several editors which cannot easily handle 
strings of characters longer than 256 without carriage returns, its a 
mess! 


14.A.5 BBS MESSAGES: You can greatly simplify operation with a 
BBS if you include BBS control messages within your text. Consider the 
following simple message: 

S KA7AGH @ KA7AGH.OR.USE.NA 

NODES 

Hi Jim — 

How is progress going on the new node? 

73 de Jim 

/ EX 

b 


A message of this type is sent from the basic BBS prompt. The first line 
is the "addressed send command" to the BBS. It returns with a request 
for the "subject" which is satisfied by the second line. Once the subject 
line is satisfied, it accepts message text; lines 3, 4, & 5 are recognized as 
message. The "/EX" terminates the message and the "b" disconnects 
you from the BBS! All you have to do in this scheme is connect to the 
BBS! 


14.B NON-TEXT FILES 


Non-text files are all those other computer files. They may be programs. 
They may be graphic files ranging from bit-map "paint" to "AutoCAD" or 
other technical files. In addition, Macintosh files have attached to them a 
"resource fork" which contains the "icon" for the file as well as 
information about the kind of program which created the file. In these 
cases, the file contains many non-text characters. As usual, there are 
several ways to deal with this situation. 


14.B.1 CONVERSION TO TEXT: There are programs which will 
convert a non-text file into a text-only form. For the Macintosh, 
"BINHEX" encoding within "Stuffit" is one. A procedure named 
"UUENCODE" and "UUDECODE" does this for DOS files. 


One of the problems with conversion to text is that the file size gets 
bigger (by about 2X). This is usually dealt with by compressing the 
original file. For most Macintosh files, "Stuffit" reduces files to about 
50% of their original size. For DOS machines, the share-ware program 
"PKZIP" is a popular compression choice. Both Stuffit and PKZIP 
permit you to bundle together several files into a single "batch". 


Once a text-version of the file has been created, it can be sent as 
described in section 14.A. The person receiving the file must have 
access to the proper decoding program. Stuffit both encodes and 
decodes BINHEX. Likewise the appropriate uncompression is required 
if this was done in the first place. 


It should be pointed out that after conversion to text form, any computer 
can handle the file. This does not, however, give PCs the ability to use 
Macintosh files! 


14.B.2 TRANSPARENT TRANSFERS: One of the problems with file 
transfers is the interpretation of file characters by the TNC. For 
example, if the the file happens to have a character which is the same as 
"control-C", the TNC immediately switches out of CONVERSE mode 
into COMMAND mode. At this point, everything grinds to a halt. 
TRANSPARENT mode was designed specifically for this circumstance. 
When in this mode, all characters are ignored by the TNC except for a 
very special set of characters which is not likely to be encountered in a 
file. You may, in fact, have to ure TRANSPARENT mode with some of 
the protocols describe in the following section. 


For TNC2 clones, this mode is entered from the COMMAND mode by 
typing cmd: TRANS. From this point on, the normal "control-C" has 
no effect! There are no "send packet" characters like the carriage-return 
in CONVERSE mode. Instead, a packet is sent when there are a certain 
number of characters accumulated in the TNC or when a certain time 
has passed. The number of characters is set in TNC2s with PACLEN; 
the time interval is set in TNC2s with PACTIME. The TNC does not 
echo these characters to the terminal screen as it normally does in other 
modes. 


No matter how the TNC is set, it sends and receives full 8-bit 
characters. You should have the terminal program set to operate with 8 
bits and NO parity. 


TRANSPARENT mode can be exited in TNC2s in several ways. Some 
terminal programs allow the sending of a "break character". In actuality, 
this is not a true character and is not in the ASCH table. Sending this 
condition usually requires a menu selection in the terminal program. 


The second exit from TRANSPARENT mode in TNC2s is governed by 
a parameter called CMDTIME. After the last character is sent, you must 
wait a time equal to CMDTIME. Then, during a the ttme CMDTIME to 
2*CMDTIME, send the command character 3 times. Then, during the 
interval from 2*CMDTIME to 3*CMDTIME from the last character, 
there can be no keyboard entries. If you have been successful, you will 
see the command prompt! I find it useful to use a value for CMDTIME 
which is not too short (so that it is missed) or too long (which is 
frustrating). For me, 5 seconds has worked. Thus, I wait at least 5 
seconds after the last file character, then within the NEXT 5 seconds, 
type 3 control-Cs, then wait another 5 seconds for the prompt. 


14.B.3 FILE TRANSFER PROTOCOLS: Most terminal programs 
which were originally written for use with telephone modems support a 
variety of "modem" protocols. These include XMODEM, YMODEM, 
ZMODEM, and KERMIT. We should not forget, here, FTP used by 
TCP/IP stations. The same protocol must be used by both stations 
involved. 


Among packet users, a number of programs have available a protocol 
called "YAPP" (Yet Another Packet Protocol). Another is PZC binary 
exchange protocol supported by LanLink software. 


The author has not had much experience with these protocols, yet. It is 
quite obvious, however, that it may take some experimenting to make 
them work through TNCs. In part, this is due to the delays between 
send and acknowledge which is not present when using telephone 
modems. 


14.C FILE TRANSFER CIPHER? 


The question has occurred to the author and others about whether 
compressed, "binhexed", or plain "modem" file transfers fall under the 
FCC's prohibition against "ciphers". 


The point to begin when considering this issue is, of course, Part 97 of 
the FCC regulations which governs amateur radio. The specific part is: 


97.113 (d) No station shall transmit: music; 
radio-communications or messages for any purpose, or in 
connection with any activity, that is contrary to federal, state, 
or local law; messages in code or ciphers where the intent is 
to obscure the meaning (except where specifically excepted 
elsewhere in this Part); obscene, indecent, or profane words, 
language, or meaning; and/or false or deceptive messages 
or signals. 


It should be quite clear that "intent" is a major component of the 
prohibition. When a file transfer is done, the intent is not to obscure 
meaning; instead, it is to carry out the most efficient transfer. 


Furthermore, just because it may appear as jibberish to someone else, 
that is not evidence of code or cipher. To someone without a TNC, a 
packet transmission is undecipherable! Just because somebody else 


cannot immediately translate it does not make it a prohibited 
transmission. 


The author wants to thank Mike Curtis (wd6ehr@k6ve 
.#S0ca.ca.usa.na) for the insight concerning this issue. 


14.D FILE TRANSFER SUMMARY 


File transfers can be carried out on packet. It can be done as a text file 
or using one of the file transfer protocols. Be prepared to experiment. 
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To many hams, TCP/IP (particularly in the forms of NET & NOS) is 
just a fancy mailbox. TCP/IP is, or can be, much more than that. This 
chapter will try to give a wider view of TCP/IP. It is not intended to 
provide information for setting up a TCP/IP station. See Chapter 19 
(Volume 2) for availability of TCP/IP software. 


Interest in TCP/IP has been growing steadily among hams. Its popularity 
is largely due to the develpment of NET and NOS by Phil Karn, KA9Q. 
Versions are available for many computers including PCs, Amigas, & 
Macintoshes 


15.A WHAT IS TCP/IP? 


TCP/IP stands for Terminal Control Protocol/Internet Protocol. While 
the native environment for AX.25 might be considered radio, the native 
environment for TCP/IP is Ethernet. This is a cabled network widely 
used to link computers. In spite of these differences, these two 
protocols essentially share common lower levels of the layer model (see 
section 11.B). In radio enviroments, the two differ most obviously in 
how packets are moved. 


TCP/IP is strongly associated with The Internet. The Internet is a 
system of linked computer networks. Its development was promoted by 
the U.S. government's National Science Foundation. Initially, it was 
intended as a network to link research activies at universites and 
government laboratories. It has since grown to include many companies 
and is now international in extent. Linking takes place in many ways 
including microwave, optical fiber, and satellite. The standard data rate 
is about 10 MB (10 MegaBaud). It is now being pushed to speeds 
approaching 100 MB. See the Bibliography in Chapter 25 of Volume 2 
for printed information about TCP/IP and Internet. 


What is normally thought of as TCP/IP is actually a collection of 
protocols. In addition to the formal IP (Internet Protocol) and TCP 
(Terminal Control Protocol), there are ARP (Address Resolution 


Protocol), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer 
Protocol), and TELNET (an internet interface allowing non-TCP/IP 
connections). Many of these will be discussed briefly in this chapter. 
There are also a number of other protocols which are considered part of 
TCP/IP but with which hams are less involved. 


15.B ADDRESSING 


TCP/IP addressing differs quite significantly from that of AX.25. All 
TCP/IP stations should have a numerical address assigned by an area 
address coordinator. The address is of the form aa.xx.yy.zz. This 
address is composed of 4 numbers, each in the range from 0 to 255. 
When expressed in binary, each number occupies 8 bits; thus, the entire 
address can be expressed as a 32 bit quantity. 


The first number specifies which network the installation is associated 
with. Hams are assigned to an amateur network designation even though 
their connection with each other might be through a university or some 
other network. Our designator is 44 so that all ham IP addresses are of 
the type 44.xx.yy.zz. The middle two parts of the address are generally 
associated with a specific physical location. The last part is associated 
with a specific machine. Actually, if a machine joins several networks, 
there is a separate address for each connection to that machine. 


One of the ways hams express the numerical address is to convert the 
last three sections to hex. The hex (hexidecimal) number system is 
base-16 and counts 0,1,2,...,.9,A,B,C,D,E,F. The hex number 10 is 
decimal 16 (1*16+ 0) and the hex number 5A is decimal 90 (5*16 + 10). 
The first section is ignored because all hams have the same 44. As an 
example, the author's IP address is 44.26.1.2. The number 26 has the 
hex value of 1A (1*16 + 10). The number 1 has the hex value of 01. 
The number 02 has the value 02 (11*16 +40). In this form, it is 
expressed as 1A0201 and can be used as a node alias in the AX.25 
network. 


There is also a name associated with each machine. In the case of 
hams, all are of the form callsign AMPR.ORG. Again, in the author's 
case, itis KA7ZEHK.AMPR.ORG. This address is called a domain name. 


As you come across systems tied into The Internet, you will also see 
addresses like guille.ece.orst.edu. This computer is part of the edu 


(education) network. It is at the location orst (Oregon State University). 
At that location, it is in (sublocation, department, division, etc) Electrical 
& Computer Engineering (that is, ece). Finally, the machine is named 
guille. We will see in discussions about ARP how this domain name is 
related to numerical addresses. 


As an aside, there are only a few highest level domain names. Two have 
been used above. EDU is used for educational institutions and ORG is 
used for an organization not otherwise on the list (ie, hams). Other such 
domain names include COM for commercial organizations, GOV for 
U.S. government agencies, MIL for U.S. military organizations, and NET 
for centers involved with internet organization and management. Sites in 
foreign countries uses a country code in the last position of the domain 
name. 


The next higher levels of the domain name are called subdomains. In the 
case of amateur domain names, the AMPR denotes something like 
AMateur Packet Radio. 


15.C TCP/IP MESSAGE TRANSPORT 


Message transport for TCP/IP uses datagram or connectionless methods 
previously disussed in Chapter 11.E. Recall that in earlier discussions of 
AX.25, a link is established between two locations by making a 
connection. This connection is made when one requests the other to 
establish a link. When the second acccepts the request and replies to the 
first, the link is established. 


The datagram style is quite different. The sending location simply 
transmits an Un-numbered Information (UD packet. It is addressed to 
the neighbor which the transmitting station believes is capable of 
delivering the packet. It is then up to the neighbor to do the same until it 
arrives at the destination. 


For this datagram system to be effective, several practical matters must 

be considered. The primary is that within a particular LAN (in this case, 
stations on a single frequency), all must be able to hear each other. It is 
possible to specify digis in routing tables but that, as usual, defeats a lot 

of the other features. 


15.D HOSTS, CLIENTS, SERVERS AND SESSIONS 


The concept of a host generally does not mean much to hams unless 
they have had contact with Internet or similar computer networks. It is 
a machine which provides servers for users (that is, clients} . 


The idea of servers was introduced in Chapter 5. If you read that 
chapter and some of the following ones, the idea should not be too 
foreign. If you did not, now is a good time to go back and at least skim 
that part. TCP/IP uses the idea of servers quite heavily. Some of them 
are hidden from the user while others (such as telnet) are up front. 


A session is the time during which a user interacts with a server. When 
you ask a callbook server (section 5.D) about a callsign, you initiate a 
session. In that case, the session continues until the server hands you 
back to the host. In the case of callbook servers, that happens when the 
information about the call is delivered to you. 


In our AX.25 world, a G8BPQ node can be thought of as a host. It has 
a variety of servers attached to it. These might include a BBS, a 
converse server, and a callbook server. There are also the hidden 
servers which manage connect requests (both local and network). 
When you activate one of these servers, a session begins and the host is 
transparent to you. This state of affairs continues until the session ends 
and you are returned to the host. 


In the TCP/IP world, a host is perhaps most easily thought of as a 
TCP/IP installation. The client might be a user typing at that station's 
keyboard or it might be another ham who has connected to the station. 


While these might just be thought of as fancy names for the things 
which go on in our network (AX.25 or TCP/IP), the underlying 
concepts are quite useful. It is also very useful to have well recognized 
names for these ideas. 


15.E TELNET 


Telnet is a simple interface between AX.25 packet users and TCP/IP 
systems. All of the KA9Q programs & derivatives have this package. 
When you connect to a station using one of these programs and get a 
prompt line, it usually looks something like this: 


Area: ka7ehk Current msg# 0. 
Ty Ar Bye, Db, EF, Hyd, 1h, 170, Byes 07 Pe Ry Sel Uy Vy Wy ee > 
a 


?)help A)rea B) ye C)onnect D)wnload E)scape F) inger H) elp 
I)nfo IH)eard IP)route J)heard K)ill L)ist M)boxusers O)perator P)orts 
R)ead S)end T)elnet U)pload V)erbose W)hat X) pert Z) ap 


Area: ka7ehk Current msg# 0. 
yA; Be G,D,E) fF, Ay l,l, P70, KB, lM, 0, PB, Syl UV, Wy ky oS 


As with many mailboxes and BBSs, you get a prompt line on connect. 
Sending a ? produces the expanded list of commands. From this, it can 
be seen that the T command initiates a telnet session. When we ask for 
more information about telnet, the result is generally something like this: 
?,A,B,C,D,E,F,H,1I,IH, IP,J,K,L,M,0,P,R,S,T,U,V,W,X,Z > 


Hor 
T[elnet] <hostname> [<port_number>] 


The telnet command allows you to initiate a TCP connection from the 
NOS mailbox out across the network to another host. This allows an 
AX.25 user with nothing more than a terminal and TNC to gain access 
to the TCP/IP network. 


By including the optional port_number, you can connect to any TCP 
server at the given host. The default is to be connected to the 
"telnet" server, which in the case of NOS software, is the MBOX. 


To quit the session at any time, enter the escape character (<CTRL>X 
by default, can be changed with the E[scape] command). 


Area: ka7ehk Current msg# 0. 


On the surface, this may seem like so much gibberish, so lets look at 
what happens in actual use. In the author's area, there are a number of 
TCP/IP installations. One is an internet gateway and one is a 
development site for JNOS40 software (see Chapter 25, Volume 2, for 
more details). The following is an example which begins as a normal 
AX.25 connection to JNOS40. Then, a telnet session to 
wg7j.ece.orst.edu. In this case, the result is not particularly interesting 
because the result is the same as if one did a direct AX.25 connection to 
IPOSU (the AX.25 node name for wg7j.ece.orst.edu). But what is 
different is the login/password requirement. 


cmd: c jnos40 
cmd:*** CONNECTED to JNOS40 
NOS for the DataEngine. 


Type ? for help 

t wg7j.ece.orst.edu 

JNOS40:WG7J-1} Trying... the escape character is: CTRL-T 
JNOS40:WG7J-1} Connected to wg7j.ece.orst.edu:telnet (escape enabled) 


KA9Q NOS (wg7j.ECE.ORST.EDU) 


Use your callsign as login. 


login: ka7ehk 
Password: { 


Where telnet is the most interesting is internet access. For those who 
are familiar with the workings of internet, this does not represent any 
problems. But if you have never used internet, it can be mysterious, 
indeed. If you need help, section 15.1. 


15.— SIMPLE MAIL TRANSFER PROTOCOL (SMTP) 


The Simple Mail Transfer Protocol is a procedure for sending mail 
between TCP/IP stations. SMTP causes mail to be moved in much as it 
is between AX.25 store-and-forward BBSs. But SMTP generally 
involves movement between TCP/IP stations (including MSYS BBSs 
which have TCP/IP capability). 


SMTP is a protocol which is used with NOS/NET software. Regular 
AX.25 users see its effect only when such a message is moved from the 
TCP/IP world to the AX.25 world. The most obvious difference to 
users is the message header; it is quite a bit larger than AX.25 BBS 
messages. This factor has often lead to criticism of TCP/IP as 
producing BBS mail which is too large. 


15.G FILE TRANSFER PROTOCOL (FTP) 


The File Transfer Protocol is a method for moving files through a 
TCP/IP system (including Internet). One may initiate an FTP session 
and request that a host send a file to you. The host need not be a local 
one (so long as there is TCP/IP routing to the host). In fact, through 
Internet, one can have access to files in other computers world-wide. If 
you are not familiar with the idea of file transfers, see Chapter 14. 


It is often through FTP that new versions of NOS are made available. 


15.H ADDRESS RESOLUTION PROTOCOL (ARP) 


Back in section 15.B, the subject of IP addresses was opened. One of 
the questions left unanswered in that section was: how do messages get 
routed to other hosts (that is TCP/IP stations). A second unanswered 


question is how addresses get translated between names and numbers. 
The Address Resolution Protocol is (at least partially) a solution to both 
questions. 


15.H.1 ARP On the Air: Suppose that one TCP/IP station, say 
44.26.1.2 (the author, ka7ehk.ampr.org) wants to send a message to 
44.26.1.8 (kb7irs.ampr.org). 44.26.1.2 sends a special ARP packet. 
This packet basically says: what ham station out there has the IP address 
44.26.1.8? In this case, it is answered by KB7IRS which says I DO. 
After this exchange, KA7EHK constructs packets with KB7IRS as the 
to-call and KA7EHK as the from-call, then sends them as a broadcast or 
UI packets. 


If there was no response, then it is assumed that the specified TCP/IP 
station is not part of the LAN. LAN, by the way, is an acronym for 
Local Area Network. Messages to destinations which are not LAN 
members are directed to a gateway which may be a BBS or a formal 
gateway into internet. 


15.H.2 DOMAIN NAME SERVERS: A key part of address resolution is 
the domain name server. The domain name server is a device which 
keeps a list of domain names and associated numerical addresses. It is 
generally easier for most of us to remember names than numbers. But 
the TCP/IP system needs the numerical addresses. The domain name 
server provides translation from domain names to numbers. 


It is not necessary that all of the elements of a domain name server be in 
one location (especially with Internet access). In fact, there is an 
AMPR.ORG name server at University of California, San Diego (UCSD). 
If a local name server is queried about an amateur domain name, it is not 
a local name, and there is Internet access, the UCSD server is queried 
for the information. You, as a user, will never know as it all happens 
behind the scenes. 


KA9Q software includes a simple name server. In general, this is a 
simple list which the operator must construct. Sometimes, it is done 
manually and sometime using lists which are circulated among users. In 
such lists, the user may attach any name (not just the formal Internet 
domain name) with a numerical address. For example, I could put in my 
list the name CALVIN for 44.26.1.8. Whether or not that is that 
stations correct domain name is irrelevant. It only matters if a network 
domain name sever must be used. 


15.1 A LITTLE BIT (MORE) ABOUT INTERNET 


Internet provides a dizzying array of services and it seems that the list 
grows daily. But two of the early services are of particular interest to 
hams. These are E-mail and News Groups. 


E-mail gives one the capability to send messages (that is, mail) to anyone 
with Internet access. While many hams have heard that this is possible, 
one of the most frequent questions is HOW? To send or receive E-mail, 
one needs access to a host which has both Internet access and a mail 
server. In the author's case, the local BBS is a JNOS installation with 
Internet access. It accepts both ham store-and-forward hierarchically 
addressed messages and messages addressed with Internet addresses. 
As an AX.25 user, one would connect to the BBS and S name @host 
instead of S callsign@bbs. The name and host for the destination must 
be known before the message is deposited on the BBS. The same AX.25 
user could tell other Internet users to address mail to the user @ host. 
In the author's case, the host BBS is WG7J.AMPR.ORG and the 
complete address would be KA7EHK @ WG7J.AMPR.ORG. 


News Groups also include Mail Groups. These are organized around a 
variety of technical topics including networking, TCP/IP, NOS, etc. 

The list is very large (about 5000 News Groups & 5000 Mail Groups). 
News Groups are distributed as bulletins to the whole Internet and are 
available for reading at many locations. An example of this is 
rec.ham-radio. Mail is forwarded as a single (sometimes large) message 
to each participant. One may simply read the messages or may 
participate in the discussion by sending an e-mail message to the group 
facilitator. If the message is in comment about someone else's message, 
that person is often forwarded a copy so that a reply can accompany 
your message. Your message then becomes part of the next distribution. 
The easiest way to find out about such News Groups & Mail Groups is 
to ask at the computer department of your local university. 


15.J A WORD ABOUT SOFTWARE 


Almost all ham operation with TCP/IP makes use of software originally 
written by KA9Q. The first try was called NET. It used the computers 
native operating system. The second version was called NOS and uses a 
special operating system for PCs which handles the multi-tasking needed 
for operation of many servers with multiple clients. 


Phil Karn, KA9Q, unlike most program writers, has made the original 
source code of the programs available. He wanted others to be able to 
build on the core of his work and add the features needed to make it 
better for users. 


NET, because of its use of native operating systems (that is, DOS for 
PCs) could (with some difficulty and limitation) be translated for other 
computers. Thus, there are versions for Macintosh and others. But, 
because of its special operating system, it is likely that NOS will never be 
available for anything other than a PC. 


Because of the availablility of the source code, there have been quite a 
few versions of NET and NOS. NET-MAC (in several versions) is for 
Macintoshs. Because of the superiority of NOS, NET is hardly used on 
PCs any more. The original version of NOS is also rarely used because 
of the improvments in subsequent versions. The PAOGRI version of 
NOS is fairly popular and is quite close to the original. JNOS (WG7J) 
version adds both a good BBS interface for users and much superior 
node operation. JNOS4O0 is a version of JNOS for the V40 
microprocessor (a super-8086) which is used in the Data Engine. 
WNOS is a version being developed in Germany. And there are likely at 
least several more. 


15.K MIXING TCP/IP AND AX.25 


Until a few years ago, it was widely assumed that AX.25 and TCP/IP 
would be relatively separate networks. In many areas, this is true. But 
things have changed significantly with JNOS, TheNet-X, and G3BPQ 
with IP routing (see Chapter 25, Volume 2). 


But mixing of AX.25 and TCP/IP extends beyond this. There is now 
tunnelling of AX.25 over TCP/IP in which TCP/IP is used as the 
physical layer (see section 11.C) for AX.25. This system is now in use 
for BBS forwarding between a number of north American sites using 
Internet. 


It also possible to tunnel TCP/IP over AX.25 to link regions of ham 
TCP/IP activity when there is no IP routing between the regions. 
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REALLY WANT TO 
OPERATE A NODE? 


Every now and then packeteers get a strange urge. Why can't I have a 
node like everyone else does? This chapter attempts to help you answer 
that question when it arrives for you. We will use the term node to refer 
to a hilltop site rather than a node associated with a bulletin board. 


16.A. DOES THE NETWORK NEED ANOTHER NODE? 


There are many reasons why another node might be desirable and as 
many or more reasons why another node might be a bad idea. Here are 
some of the network-related issues. 


16.A.1 Inadequate access: Perhaps an area (a valley, for example) 
has poor network access. Maybe retry rates are very high. Perhaps 
everyone needs to use a digipeater. This is an excellent reason to 
consider adding a node to a packet network. 


16.A.2 Poor network link: Perhaps your local network has a poor 
quality link. A new node located between the two having the problem 
could be an excellent addition. But make certain, first, that the problem 
is not in the nodes, themselves. There could be radio problems, antenna 
problems, coax problems, or any one of several more problems. Also 
make certain that the difficulty is not due to an excessive number of 
other nodes on the same frequency. In this case, just adding another 
node will make things worse, not better. 


16.A.3 Network restructuring: One of the most effective ways to 
improve a network is to change its structure. If the network is a 
single-frequency system (users and linking on the same frequency), then 
convert it to a backbone system (see section 8.D). If the network has a 
large area backbone, convert it into a clustered system. You can 
contribute by offering to add a port to an existing node to make either of 
these happen. 


16.A.4 User access: In high population density areas, the number of 
nodes is especially important. There are some useful guidelines 

which can help show if there are too few or too many nodes. In the 
United States, roughly 1 in 2000 of the population has an amateur radio 
license. Based on TNC sales, it is thought that about 50% of hams own 
a TNC; this percentage may be optimistic but appears reasonable in 
some high population areas. Thus, there is about 1 TNC per 4000 
population. During peak operating periods (SPM to 8PM local), perhaps 
10% to 25% percent of the TNCs may be on simultaneously. Thus, 4 
TNCs per 100,000 population (40 TNCs per 1 million population) are 
active simultaneously. Nodes begin to have problems with 10 
simultaneous connections on the same frequency if the channel is 
perfect (that is, everyone can sense everyone else's transmission); in less 
perfect conditions, the capacity may be half that. To service the users 
who would like to operate during peak periods, something on the order 
of 8 nodes per million population is not unreasonable. 


16.A.5 Improve network redundancy: Network redundancy? What's 
that? In many networks, there are locations where the failure of one 
node leads to a complete severance of the network without any practical 
way around the failure (single-point-of-failure). Network redundancy 
adds parallel paths so that the failure of one does not lead to failure of the 
network. 


16.A.6 Can another node possibly hurt?: Yes! Simply adding one 
more node to an already overloaded system will make things worse, not 
better. If the node does not serve a clear purpose, then consider putting 
your efforts somewhere else. 


16.B. WHAT'S THE DOWNSIDE? 


Operating a node is much like operating a voice repeater. Here is some 
of what it involves. 


16.B.1 Cost: Nodes do not come cheap. If you were to purchase 
everything needed, figure on the following for a single port of a TheNet 
node: 


TNC S125 


RADIO $450 
ANTENNA $100 
PWR SUPPLY $50 
MISC S50 

TOTAL oro 


At severe-weather sites, a durable antenna may actually cost $200 or 
(much) more. 


Site rental is also a major issue. At U.S. government sites in the west 
(Forest Service, Bureau of Land Management, etc), yearly rents 
anywhere from $500 to $1000 may be demanded. It is often possible to 
reduce this figure through certification by your county and state 
emergency services office. If the site is private, there may be more 
leeway but expect, at the very least, to pay for a share of electrical 
costs. 


16.B.2 Pressure: If the node fails, you may experience a lot of 
pressure to get it operating again. This is especially true if the node is a 
single-point-of-failure or if it is one on which bulletin boards depend. 
When winter weather makes access difficult, it may be impractical, if 
not impossible, to meet these demands. 


16.C. AND THE PAYOFF? 


Of course, along with cost, we expect some sort of payoff for operating 
a node. 


16.C.1 Regional cooperation: A voice repeater often requires 
community cooperation. With the exception of frequency coordination 
issues so that repeaters do not interfere or possible linking, the effort 
remains local. A node, on the other hand, is a regional device. It is part 
of a network. For this network to operate, it takes cooperation of many 
individuals and groups. Being part of this cooperative system can be an 
excellent payoff for some hams. 


16.C.2 Public service: A node can be a very significant public service 
tool. In many areas, county emergency services organizations depend 
on packet radio for some of their communication. Your node, if it is 
properly designed and located, can be part of this. Likewise, providing a 


highway for bulletin board forwarding or for keyboard-keyboard 
communication by others represents a public service. 


16.C.3 Technological growth: Operating a node is not simple. It 
requires learning a whole new set of skills. This learning can be a 
significant incentive for some. 


16.C.4 Recognition: If your node provides a genuine service, your 
efforts will be recognized by users. You may never hear about it. But 
packeteers will recognize you as a supporter of packet radio who "puts 
money behind the words you speak". If your node is more of a 
hindrance than a help, folks will recognize that also. It may take some 
time, but this too will be recognized. 


16.D. A PLEA! 


Before you go very far thinking about putting up a node, please talk to 
node operators in the area you are considering. Courtesy, at the very 
least, demands it. Ask them a some questions; your efforts will more 
likely to be well received and effective. Here are some of the things to 
ask: 


16.D.1 Does the idea make sense?: Often, those node operators 
can tell you if your proposal makes network sense. They can often tell 
you about areas with difficult access since they have likely heard 
complaints. 


16.D.2 What are the near-term network plans?: Packet networks 
are undergoing rapid change. In some areas, there are well thought out, 
written, plans. But this are the exception rather than the rule. More 
often, a few node operators may have an understanding among 
themselves about how they want to improve things. 


These plans may effect you in two ways. Your effort can help to make 
the improvements happen. But, also, if you add a node to your local 
network, you may find changes which will require you to change 
frequencies, change bands, or change baud rates. If the latter is the 
case, you should know about it before you start! 


16.D.3 What frequencies are available?: The question affects both 
user frequencies and linking frequencies. If the question is one of a user 
frequency, the node ops may be able to suggest something themselves. 


If there is a frequency coordinating group in your area, they should be 
able to tell you how to reach it. 


With respect to linking frequencies, which one is appropriate? Often, 
that tantalizing link with only two nodes on it is designed that way as a 
point-point link (see section 8.D). In other cases, your proposal may 
appear as a hidden node to some of the other nodes on the backbone. In 
yet other cases, there may already be too many nodes on one frequency. 
The best backbone frequency for your node may not be obvious, so ask. 


16.D.4 Is your proposal welcome?: In some areas of the U.S., 
groups have a very strong hold on network linking. They often attempt 
to control very tightly what nodes are a part of that network. If such is 
the case in your area, and your efforts are rebuffed, you might check to 
see whether or not there are other organizations which also organize 
networks or if there are networks which the group does not control. If 
you fail on all counts, you might try some other hobby! 
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REALLY WANT TO 
OPERATE A BBS? 


There is another urge which often strikes packeteers. It is the 
BBS-urge. There are many parts of this issue which also involve node 
operation. If the BBS urge has hit you, please read Chapter 16, also. If 
this chapter looks like Chapter 16, it is because the questions are so 
similar. 


17.A. DOES THE NETWORK NEED ANOTHER BBS? 


There are many reasons why another BBS might be desirable and as 
many or more reasons why another BBS might be a bad idea. Here are 
some of the network-related issues. 


17.A.1 Inadequate access: Perhaps a hilltop node has no BBS 
associated with it. The users of this node must then traverse the 
network to use another. Every message read must cross the network 
once for every reader. If there is a local BBS, the message travels 
across the network once, or perhaps twice (if the BBS forwards 
messages on somewhere else). If there are a sizable number of BBS 
users on a node, the network will actually be more lightly loaded through 
the addition of a BBS. 


17.A.2 User access: In high population-density areas, user access to 
a BBS is as important as it is to anode. A BBS tends to slow 
significantly when there are more than 3 or 4 simultaneous users. 

The same arguments used in section 16.A.4 would then suggest perhaps 
a minimum of 4 bulletin boards per million population if 50% of the 
peak-time users try to access a BBS. 


17.A.3 Improve forwarding redundancy: Forwarding redundancy? 
It is the same idea as network redundancy. If one BBS is heavily relied 
on to forward between two parts of the network and it fails (as it will, 
sooner or later), an alternate BBS can fill in. This is somewhat less 
important an issue, however, than the single-point-of-failure in a 


network. In this case, the messages can still travel between bulletin 
boards, even though they are separated by more nodes than normal. 


17.A.4 Can another BBS possibly hurt?: Yes! There are examples 
far and wide of a second BBS added to a hilltop node to relieve 
congestion. But when the node links to the BBSs on the same frequency 
as the one used by regular users, the problem is worse, not better. 


17.B. WHAT'S THE DOWNSIDE? 


Operating a BBS is much like operating a node. But there is more. 


17.B.1 Cost: BBSs do not come cheap. If you were to go out and 
purchase everything needed, figure on the following for a single port 
BBS: 


TNC S125 
RADIO $450 
ANTENNA $100 
PWR SUPPLY $50 

MISC $50 

COMPUTER $800 
TOTAL $1575 


The estimated computer cost will probably purchase you a used 
monochrome machine with a small hard-drive. Do not plan on using 
your regular computer simultaneously as a BBS and for other home uses. 
It is more trouble than it is worth and mistakes while running other 
programs can be detrimental to BBS operation. Be also aware that 
almost all BBS programs are for DOS machines; there does not yet seem 
to be a real Macintosh or Amiga BBS program. 


17.B.2 Pressure: If the BBS fails, you may experience a lot of 
pressure to get it operating again. This is especially true if there are 
many users or it is associated with emergency services operations. 
Failures will come. The computer seems to be the most failure-prone 
part and the hard-drive the most failure-prone part of the computer. 
Backup, backup, backup! 


17.C. AND THE PAYOFF? 


Of course, along with cost, we expect some sort of payoff for operating 
a BBS. 


17.C.1 Regional cooperation: Operating a BBS means sharing 
forwarded messages with neighboring BBSs. This takes cooperation. It 
also means that you should become part of this cooperative process. 
Doing so means that you should be able to reach consensus with others 
and learn how to disagree without being disagreeable! 


17.C.2 Public service: A BBS can bea very significant public service 
tool. In many areas, county emergency services organizations depend 
on packet radio for some of their communication. Handling NTS traffic 
is beneficial, also. 


17.C.3 Technological growth: Operating a BBS is not simple. It 
requires learning a whole new set of skills. This learning can be a 
significant incentive for some. 


17.C.4 Recognition: If your BBS provides a genuine service, your 
efforts will be recognized by users. You may never hear about it. But 
packeteers will recognize you as a supporter of packet radio who "puts 
money behind the words you speak". 


If your BBS is more of a hindrance than a help, folks will recognize that 
also. It may take some time, but this too will be recognized. 


17.D. A PLEA! 


Before you go very far thinking about putting up a BBS, please talk to 
BBS operators in the area you are considering. Courtesy, at the very 
least, demands it. Ask them a some questions; your efforts will more 
likely to be well received and effective. Here are some of the things to 
ask: 


17.D.1 Does the idea make sense?: Often, those BBS operators 
can tell you if your proposal makes network sense. They can often tell 
you about areas with difficult access since they have likely heard 
complaints. 


17.D.2 What are the near-term network plans?: Packet networks 
are undergoing rapid change. BBS forwarding is greatly effected by the 
organization of the network on which it relies. 


Perhaps the operator of local hilltop node would like hilltop-BBS linking 
on a separate frequency from users. This generally improves BBS (and 
node) operation substantially. When this change is made, forwarding in 
and out of the BBS are not seen as traffic by users. It may mean that a 
radio you had planned to use is no longer appropriate. Similarly, planned 
changes in radio baud rate can effect your modem needs. 


17.D.3 What frequencies are available?: The question affects both 
user frequencies and linking frequencies. Some bulletin boards have 
more than one port. If there is going to be a separate user's frequency, 
what frequency should be used may be an issue. 


If the BBS is going to link on a backbone frequency, which backbone is 
appropriate may also be an issue. 


17.D.4 Is your proposal welcome?: In some areas of the U.S., there 
are BBS wars. Neighboring bulletin boards to not forward to each other. 
There are arguments about the types of messages to be forwarded (or 
more usually, not forwarded). There are complaints about how bad a 
BBS is for the network. 


Some node owners do not welcome a BBS. Find out before you invest! 
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COMING? 


As mentioned in the introduction, amateur packet is a very fluid area. 
Some of what we have today could be seen a few years ago and some 
could not. This is written from the perspective of mid-1993. What is 
discussed in this chapter are some of the developments which seem very 
near at hand or toward which current trends point fairly strongly. There 
will certainly be some hits and some misses. But these topics should 
help to keep some currency to the book for a little while! 


18.A. HIGHER SPEEDS 


What's the big deal about higher baud rates? Isn't 1200 baud good 
enough? The same might have been said about 45mph Ford Model-T's. 
Now, much of the "high" baud-rate activity is on backbone links but 
there are areas of the U.S. where users operate at 9600 baud or higher. 


18.A.1 WHY HIGHER BAUD RATES? The reasons is pretty simple. 
Our frequencies are limited; higher baud rates let more packets flow on 
the same set of frequencies. A less obvious reason is that each station 
occupies a given frequency for a smaller time interval (given the same 
number of characters); thus, more stations can be accommodated. A 
third reason has to do with usability. As baud rates increase, servers 
running on distant nodes seem to you as if they are local. Thus, it is 
possible to distribute the "power" around a network; then there is less 
pressure for call-book servers, converse servers, etc to be available at 
everybody's node. 


18.A.2 WHY DOES EVERYONE USE 1200 BAUD? First, everyone 
doesn't use 1200 baud (even discounting the lower baud rates used on 
H.F.)! But, still, why do most packet users use only 1200 baud? The 
reason is pretty simple. Until quite recently, hardware (that is, TNCs) 
running faster than 1200 baud were fairly scarce. 


The standard TNC2s have built-in to them a modem disconnect header. 
This is a place where a non-1200 baud modem can be installed. Almost 


as long as there have been TNC2s, there have also been 2400 baud 
plug-in modems. Unfortunately, the number of 2400 baud users have 
never reached a critical mass required to generate corresponding support 
from node owners; a 2400 baud signal won't work on a 1200 baud 
node! Also, the plug-in modems cost nearly half as much as the TNC, 
itself. Many felt that the added expense was not worth the rather 
minimal improvement. But 2400 baud has one advantage; it can be used 
on radios just like 1200 baud; both are AFSK (see section 1.A). One of 
the additional difficulties is that once a TNC has been modified for a 
baud rate other than 1200, it is difficult to switch it back. 


Several packet modems are now available for use at 9600 baud or 
19.2Kbaud. Plug in modems for these baud rates are also available for 
TNC2s. 


For higher baud rates, true FSK (also see section 1.A) is generally used. 
This creates a problem with radios. With FSK, one cannot simply take 
audio from a loud-speaker jack and put audio into a microphone jack. 
The modulation is different and few radios accommodate this without 
modification. 


18.A.2 BAUD RATE AND MODULATION: One of the factors 
governing baud rate is bandwidth. Amateur transmissions are limited in 
their bandwidth. Within the 6 meter (50-54MHz), 2 meter 
(144-148MHz) and 1.25 meter (222-225 MHz), we are limited to 20KHz 
bandwidth. At frequencies above 420MHz, wider bandwidths are 
allowed. 


Bandwidth is the spread of frequencies occupied by a signal. The 
bandwidth of an unmodulated signal is nearly 0. The term nearly is used 
because there is no such thing as an absolutely pure signal; even the best 
there is at the present (Cesium frequency standard) is not absolutely 
pure. The bandwidth occupied by a signal and its modulation depends 
on the type of modulation and the information which the modulation 
carries. That is, SSB has different bandwidth than FM for the same type 
of information. In our case, the information is digital. And, generally, 
the MINIMUM FM bandwidth needed is about twice the baud rate. 
Thus, 9600 baud needs at least 19.2KHz bandwidth. Thus, with the 
proper modulation techniques, 9600 baud could be legally used on 2 
meters! 


At 2400 baud and slower, AFSK (that is 2-tone) modulation of FM 
transmitters is normally used on VHF. At 9600 baud, switching between 


two tones becomes impractical because of the short time spent on any 
one tone; there are too few cycles of the tone to accurately tell which is 
which. Thus, direct frequency shift keying is used. 


There are a few packet-ready radios which modulate and demodulate 
FSK signals. At the present time, they are fairly expensive and a bit 
tricky to operate. Other transceivers can be used but require 
modification. Unfortunately, this step is one which many hams are 
reluctant to carry out. 


18.A.3 EVEN HIGHER BAUD RATES: Up to this point, it may have 
appeared that 19.2Kbaud is about as fast as anyone is thinking about. 
That is not so. 56Kbaud systems are in use in several parts of the U.S. 
Because almost everything is home-brew at these rates, it has tended to 
be experimental or for point-point links. At microwave frequencies 
(1200MHz or 1.2GHz and up), baud rates of 10,000Kbaud (10Mbaud) or 
higher are being developed. 


18.A.4 WHAT ARE THE PROBLEMS WITH HIGHER BAUD 
RATES? In addition to the lack of equipment, there are some real 
technical problems at rates of 9600 baud and above. Multi-path (see 
section 3.E.1) becomes more significant at higher baud rates. The effect 
increases as baud rate increases. As bandwidth requirements exceed 
that of normal voice communication, the filtering within transmitters and 
receivers must change. Thus, for rates above 9600 baud, radios must 
almost be constructed specifically for the application. 


18.A.5 OTHER TRANSMITTER CHARACTERISTICS: In addition to 
the characteristics previously mentioned, one of the transmitter 
characteristics which severely limits the usefulness of higher baud rates 
is called t/r switching time. This problem was alluded to in section 6.G 
in discussions about BBS loading of the packet network. 


Suppose we take an ordinary transceiver which might take 300mS to 
stabilize after switching from receive to transmit. Suppose we take a 125 
character packet with an overhead of another 50 characters (about 25 
actual header characters and more for network management). These 
175 characters take 140mS at 1200 baud and 18mS at 9600 baud. The 
total transmit time is the sum of the stabilization time at the beginning of 
the transmission and the time needed to send the packet. Thus our 
average transceiver would take 300+140 or 440mS at 1200 baud; at 
9600 baud, it would be 300+18 or 318mS. Obviously, in this case, 
higher baud rate gains rather little. Even at a stabilization time of 100mS, 


the transmit time only changes from 240mS to 118mS. Note that even 
in this case, an 8 times increase in the baud rate has only halved the time 
the transmitter is on. 


The consequence of this factor is that transceivers with t/r switching 
times under 25mS (preferably even less) are needed to see the full 
benefit of higher baud rates. Attempting to use old transceivers with 
slow t/r switching at high baud rates is thus an illusion with very little 
benefit for the cost of high speed TNCs. 


18.B. MICROWAVE 


Microwave is one of the big frontiers for amateur radio and packet is no 
exception. Microwave permits wider bandwidths and higher baud rates. 
We are already seeing conversion of surplus military and telephone 
microwave to amateur use. It seems likely that, with this equipment 
available, we will see very high bandwidth amateur microwave links 
which carry multiplexed (that is, shared) voice and data. Thus, there 
might very well be repeater-repeater voice linking and node-node packet 
links on the same microwave signal. 


Microwave has the advantage of very narrow antenna patterns. Thus, 
the frequencies can be shared over closer distances than with lower 
frequency signals. This should particularly attractive in congested 
metropolitan areas. 


Microwave signals do tend to be effected more significantly by 
atmospheric changes. Certain weather conditions even cause loss of 
commercial microwave paths at times. Microwaves tend to be reflected 
more easily. This can be both an advantage and a disadvantage. 
Multi-path is one of the negative effects. Passive reflectors to bend 
paths on purpose are a positive effect. 


18.C. FULL DUPLEX OPERATION 


Full duplex operation is like a voice repeater. NODE1 transmits on 
frequency A and receives on frequency B. NODE2 transmits on 
frequency B and receives on frequency A. Packets can be passed both 
ways simultaneously. No waiting is required. There are no collisions 
between the neighbors. All-over character rate can be more than 


doubled (especially if real data is flowing both ways). 


The problem is that full-duplex requires twice the bandwidth. On 
microwave bands, in particular, there appears to be bandwidth to make 
this practical. 


Full-duplex is also possible on user frequencies. Most TNCs support 
either simplex or duplex operation . Duplex nodes are constructed more 
like voice repeaters than like traditional nodes. 


18.D. NETWORK STRUCTURE 


The preceding sections of this chapter and the discussion of networking 
in Chapter 8 both suggest that there are some changes in network 
architecture in the works. Especially in high traffic-density areas, the 
move toward point-point networking is already underway. In all 
fairness, however, it should be pointed out the much of our network will 
never be point-point. Many locations do not have the economic 
resources or frequency availability. 


Once point-point linking is common, there will, in all probability, be less 
reluctance to go higher in baud rate, full duplex, and microwave. This is 
because each link is the responsibility of only two node-ops; that link no 
longer has to be operated cooperatively with other nodes so long as it 
has the through-put. That is, it no longer makes any difference what 
frequency, baud rate, or other technical characteristics a specific link 
uses. So long as packets can move through, the rest of the network will 
be happy! And so will the users be happy! 


18.E. IP ROUTING 


With the advent of TheNet-X (see Chapter 25 in Volume 2) and the 
spread of TCP/IP installations (particularly JNOS), it is not hard to 
forecast the growth of IP routing. While it had often been thought that 
AX.25 (see Chapters 1 & 11) and TCP/IP could not or would not 
coexist peaceably, there is now plenty of evidence that they will. 


It does appear true that there will be IP-only networks because there are 
quite a few in operation right now. Mixed networks will bring TCP/IP 
to more users, however, without having to duplicate facilities. This will 
certainly lead to a more rapid growth of amateur TCP/IP. 


18.F. OTHER FUTURES 


There are other futures which are a lot less encouraging than those 
outlined above. Areas of the east coast in high population density areas 
are suffering now from lack of aggressive network improvement. As 
more and more users attempt to operate in this system, it is more-or-less 
rapidly grinding into a state of near-uselessness. Over-loaded 
frequencies, poor network architecture, & lack of investment in 
network facilities have all contributed. Unfortunately, this situation does 
not attract those who are capable of solving the problem! 


It is the author's sincere hope that this book may, in some way, 
encourage the continued improvement of our packet system. And where 
it seems blackest, those of good will should not give up. Find out how 
folks in other areas have solved problems similar to yours (and almost 
always, somebody has!) Then go to it! 


